Proposal: rename 'unsubscribe' to stop, or provide an alias

[metabench]

'Stop' is simpler language, and easier to type. It's got the information needed within the name, 4 letters rather than 11.

It would also raise possibilities of Subscription sharing more of an interface with other classes that have a simply named .stop method.

[ljharb]

stop would have to be paired with start or go, then, instead of subscribe?

[metabench]

One or both of them would be useful alias or replacement names for subscribe. It seems many are used to subscribe and unsubscribe, but in my opinion, shorter method names would be advantageous.

[aboyton]

You’re not really starting and stopping it though. You are for cold observables but you’re not for hot observables, they will keep publishing if you are subscribed or not. It’s shorter but not really semantically correct.

[geovanisouza92]

open/close could be a good analogy too.

[metabench]

@aboyton It's a question of starting and stopping what. While I think unclear language needs to be avoided, I was also did not immediately know what cold or hot observables are. I have come to this from writing my own evented code for a long time, then more recently have made it conform to what I see as a simple observable pattern. Rather than thinking about or using a large API, I have just had an object that raises events next, error, and complete. Then I gave it pause, resume and stop functions.

Wanting to make my code conform to appropriate standards, I went to look at what an observable officially is, and saw it's at the proposal stage here. I hope I am forgiven for my lack of knowledge of Observables, but as far as I sett it, it's yet to be settled what an Observable actually is anyway.

Reading https://medium.com/@benlesh/hot-vs-cold-observables-f8094ed53339, I question whether a 'Producer' category of object is necessary, as it's just the flow of the code that results in Observable events being called. It reminds me of the 'Controller' part of 'MVC', where the overall structure of the code and of function calls is the Controller, without there needing to be any software component which actually has that name.

Having looked into hot and cold observables, I disagree about start and stop being wrong, but it does introduce some ambiguity. Either word could refer to the component doing what it does, rather than the process overall. If the component provides a subscription, then stop meaning to stop providing that subscription makes sense, rather than to stop the data source itself (and I ask if a hot Observable can stop a Producer or other data source, and if it would be worth considering that functionality in the Observable API).

With both 'hot' and 'cold' observables, would it be worth calling one of them a 'Subscription'? Is that term more appropriate to one than the other.

I'm in favour of the TC39 committee thinking about what words that are more concise can be used to express as much information, and possibly more concise names that convey less information if they are still appropriate words. If the words are very observable-specific, it makes it harder to treat Observables as a generic class of objects that provides data in an ongoing way.

I don't think TC39 has gone in for deliberately making shorter aliases of words or function names, but I suggest doing so in cases like this, where there could be a longer name like unsubscribe, and an alias for it being stop, and with an explanation in the documentation and standard about precisely what stop stops and does not stop.

Possibly .close or .exit could be generally used words that mean more than just stop, but generally I advocate using shorter and more general words that are still very accurate given the context of what the component does.

[appsforartists]

It sounds like your main argument is "I have to type 7 fewer characters when I manually unsubscribe," which is not a compelling one.

The observable pattern is in the process of being standardized, but it's been implemented many times in userland (including in the massively popular RxJS). I'm not ipso facto against changing terminology, but I hope the barrier to do so is higher than "I don't like typing full words that are longer than 4 characters."

[benjamingr]

The observable pattern is in the process of being standardized, but it's been implemented many times in userland (including in the massively popular RxJS).

RxJS breaks pretty often for making APIs more correct or when better ones are found so I don't think that's the case we should make.

On the other hand I think the names we use are find and typing length isn't really an argument for a less-clear method name