Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subscription interface: closed method #142

Open
lucamezzalira opened this issue Feb 9, 2017 · 10 comments
Open

Subscription interface: closed method #142

lucamezzalira opened this issue Feb 9, 2017 · 10 comments

Comments

@lucamezzalira
Copy link

Hi All

reviewing the proposal I'd suggest changing the closed method name to isClosedthat would suggest immediately that the method will return a boolean value.

@appsforartists
Copy link
Contributor

It's a getter, not a method.

@ljharb
Copy link
Member

ljharb commented Feb 10, 2017

In that case, can it be a method, not a getter? Getters are slow, and foo.x === foo.x not always being guaranteed to be true is weird (not sure if that's a possibility here).

@appsforartists
Copy link
Contributor

get closed() : Boolean;

A Boolean should always equal an equivalent Boolean, so I don't think your concerns about === are relevant here.

"Getters are slow" sounds like premature optimization, especially without a citation. Can you imagine a realistic situation where the difference in speed between a method and a getter would be meaningful with regard to isClosed vs isClosed()?

@lucamezzalira
Copy link
Author

@appsforartists Sorry my bad, but the question still stand, don't you think would be more clear using isClosed instead of closed?

@RangerMauve
Copy link

It might be good to look at other JS/DOM APIs to see if isBoolean is a common trait. AFAIK, prefixing methods that return booleans is more of a Java thing and I don't recall seeing that in any DOM/Node APIs (other than in libraries).

@RangerMauve
Copy link

Are there any plain old JS or DOM APIs that also match this? The reason I bring that up is that Observables aren't made to integrate with the node ecosystem per-se, but for JavaScript as a whole. And the APIs in browsers are a big part of that.

Array.isArray() shouldn't count because it's not a method returning the current state of an object, it's checking the type, similar for isBuffer in node.

The cases in the cluster module are compelling since these are getters that return the state of an object. It'd be cool if someone also had counter examples for getters returning the boolean state of an object.

@aruns07
Copy link

aruns07 commented Feb 15, 2017

I mostly find myself using isSomethingCurrent or hasSomethingDone style of names.

Reading this issue made to think that

  • hasSomethingDone and somethingDone both tells about an event/action has happened or not in the past.
  • isSomethingCurrent and somethingCurrent tells about the current property assumption of an object.

Well English is not my first language, please correct me if following knowledge is not correct.

I think we could consider Noun, Adjective, and Verb to decide.

has[Past Verb], [Past Verb], is[Noun], is[Adjective], [Adjective] is suitable for boolean return.

hasClosed, closed sounds same and dropping prefix is better.

@mattflix
Copy link

mattflix commented Feb 15, 2018

@appsforartists wrote:

A Boolean should always equal an equivalent Boolean, so I don't think your concerns about === are relevant here.

@appsforartists, you may be surprised to see what gets logged to the console by the following code:

console.log(new Boolean(true) === true);
console.log(new Boolean(false) === false);

The closed getter on SubscriptionObserver should really be defined to return a boolean primitive, not an instance of the Boolean object type (which is pretty big footgun, and seems like an obvious mistake to me, or at least a typo that will be very important to fix).

If the current API proposal is left unchanged, it means users will have to workaround the following rather surprising behavior:

    if (subscription.closed) {
        // always executes, since closed is always a truthy value
    }

See also #184.

@benlesh
Copy link

benlesh commented Feb 20, 2018

@mattflix that seems like a typo, honestly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants