search

jasnell / proposal-istypes

TC-39 Proposal for additional is{Type} APIs
201 stars 7 forks source link

Option for non-builtins as well #39

Open brettz9 opened 6 years ago

brettz9 commented 6 years ago

While this flies in the face of the name referring to Builtin, I'd think it would be useful, as well as semantically pleasing to have another method to return the same values as in your proposal but returning {}.toString.call(val).slice(8, -1) with Symbol.toStringTag for constructed user objects.

One could thus benefit from:

switch (Types.typeOf(obj)) {
    case 'null':
        break;
    case 'MyConstructor':
        break;
    // etc.
}

While this may be technically out of scope for your proposal, I'd think it might be considered together if it is deemed worthwhile.

ljharb commented 6 years ago

"Builtin" isn't a great name here. The proposal already allows an object to define its own custom Symbol.builtin function, which allows the use case you're referring to.

brettz9 commented 6 years ago

Sure that works if a class defines it--but what about constructors beyond one's control?

ljharb commented 6 years ago

Then you're constrained to the API that code beyond your control provides you :-) having a fallback to Object.prototype.toString.call is something you can easily build in an abstraction.

brettz9 commented 6 years ago

Even the short form, {}.toString.call(val).slice(8, -1), is an ugly mess of implementation-leaking. If not integrated with this type-checking, I think it deserves its own API.