Open ljharb opened 6 years ago
Here's a particularly ugly example of this issue that perhaps will help further motivate reconsideration of this proposal or something like it: https://stackoverflow.com/a/29926193/560114
function isMap(o) {
try {
Map.prototype.has.call(o); // throws if o is not an object or has no [[MapData]]
return true;
} catch(e) {
return false;
}
}
function isSet(o) {
try {
Set.prototype.has.call(o); // throws if o is not an object or has no [[SetData]]
return true;
} catch(e) {
return false;
}
}
@ljharb ... let's start here: https://github.com/nodejs/node/blob/master/lib/internal/util/types.js
This is a recent edition to the internals of node.js (non-public API) that uses the to string approach. We can certainly reopen this but given that the code referenced above uses the solution that was offered as an alternative to this proposal, we should articulate the cases where the above code doesn't work or is not ideal.
@jasnell indeed, this has always been possible for Typed Arrays (see https://npmjs.com/which-typed-array) since it's using a getter instead of just a string. Are there no other use cases in node besides Typed Arrays?
Probably "ugly" but "working" is my solution with UUIDs as implemented in Doodad [1][2][3]. With an example like that, I hope to be able to demonstrate how important such a proposal is.
(NOTE: links are from the master branch, where code is subject to change) [1] "types._instanceof" function [2] UUIDs file for Node.js [3] UUIDs file for browsers
I'm very unclear on why this was withdrawn.
The perfect solution is "toStringTag, but brand-checking functions instead of strings" - and it's what toStringTag should have been in the first place. No other solution works because try/catch is awkward and slow, and toStringTag can be forged in both directions.
What more is needed to motivate this proposal being brought again in front of the committee?