-
Notifications
You must be signed in to change notification settings - Fork 90
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#closed should return boolean, not Boolean #184
Comments
The specs don't mention returning a Boolean object: https://tc39.github.io/proposal-observable/#subscription-prototype-object |
That's great. By "spec", I meant the text of the proposal (right next the bottom, where the SubscriptionObserver interface is shown), here: It's good to see that the typo (I guess) didn't make it into the formal spec. There should still probably fix the typo, as it may cause unnecessary confusion/angst for anybody coming to the README to become familiar with the details of the proposal. The use of |
I don’t think it’s a typo. In every current type system I’ve seen in JS, Boolean refers to the primitive, and nobody considers the existence of a boxed Boolean object at all. |
@ljharb, in Flow, the following code does not compile: function g(x: Boolean) {}
g(true); // ERROR
// g(true);
// ^ boolean. This type is incompatible with the expected param type of
// function g(x: Boolean) {
// ^ Boolean In TypeScript, too, Again, this is probably a minor point, and really just a typo. The important thing is that the formal spec (referred to by @dinoboff above) correctly shows that So, this issue can be closed, athough it would be nice if the informal README was corrected from "Boolean" to "boolean". |
I wasn’t aware of that; thanks for clarifying. In that case it should indeed be the lowercase version. |
I'm +1 on keeping the existing usage as it is what the spec uses and this is a spec repo. |
@benjamingr, not clear what you're advocating. You are suggesting that |
The
closed
getter onSubscriptionObserver
should really be defined to return aboolean
primitive, not an instance of theBoolean
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:
The text was updated successfully, but these errors were encountered: