protected instead of protected?

[retorquere]

I'd like to subclass SequentialTaskQueue; would it be possible to make next and queue protected rather than private?

[BalassaMarton]

See the new version on npm

[BalassaMarton]

Oh, never mind, I totally pushed and published this half-done :/ Made emit protected instead of queue

[BalassaMarton]

I need to think this through, since this requires TaskEntry to be exported as well.

[BalassaMarton]

My concern is that once next and queue is protected, it will probably not be enough to do anything, and the next thing we know is that everything must be visible, but then it needs to be more robust so that overriding any of these methods actually makes sense. @retorquere can you first clone the repo, make the necessary changes and subclass it in a public repo?I'd like to know if just making these private members are in fact enough, and also curious of what you're trying to accomplish.

[retorquere]

If exposing queue does to much damage, it's easy enough for me to route around it. next doesn't require anything else to be exposed, and allows hold/resume like so (I think at least).

I had planned to use the exposed queue to do cancel by arg value (sketch here), but as said, there are ways around that which do not require exposing queue.