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

Proposal: is{Type} methods #29

Merged
merged 1 commit into from
Oct 14, 2016
Merged

Proposal: is{Type} methods #29

merged 1 commit into from
Oct 14, 2016

Conversation

jasnell
Copy link
Contributor

@jasnell jasnell commented Oct 10, 2016

Introduces a proposal for adding additional is{Type} methods to intrinsic objects.

For example:

  • ArrayBuffer.isArrayBuffer(arg)
  • Symbol.isSymbol(arg)
  • and so forth...

https://github.com/jasnell/proposal-istypes

@ljharb
Copy link
Member

ljharb commented Oct 10, 2016

I would love this, but you should be aware that when I previously proposed Error.isError (since it's the only primordial without an internal slot/brand checking method on its prototype), I got a very very large amount of pushback and ended up withdrawing the proposal

https://www.npmjs.com/package/is-date-object is what you get when implementing with the committee's current recommendation (besides "don't brand check").

@doug-wade
Copy link

doug-wade commented Oct 14, 2016

It seems, from my cursory reading, that the argument comes down to "errors aren't really that different from objects and shouldn't be treated as such." I don't think that the same argument could be made about numeric primitives (for example).

@ljharb
Copy link
Member

ljharb commented Oct 14, 2016

The essence of the pushback was that many on the committee believes that code should not be brand checking, and if an object wants to pretend to be something, it should be allowed to fully perpetrate that disguise (whereas brand-checking would be an unforgeable check).

This can be merged regardless, but I want the champion to be as prepared as possible to present it - for example, Proxy.isProxy will likely never be acceptable, and although I'd love to have all the others, the reasons I've mentioned are why it won't likely even be able to achieve stage 1.

@jasnell given this, if you'd still like this PR merged please go for it!

@jasnell jasnell merged commit 56e0edf into tc39:master Oct 14, 2016
@rwaldron
Copy link
Contributor

Proxy.isProxy

This stood out as well—a Proxy should appear to be whatever the target object is, eg.

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

Successfully merging this pull request may close these issues.

4 participants