Re: [heycam/webidl] Only install @@toStringTag on the prototype (#357)

Why are we aligning with 1/4 implementations, and not 3/4?

I've thought about this a good bit since the thread mentioned above, and in general, I feel like TC39  made a serious mistake when going from ES5 builtings, for which the prototype was in fact an instance of the type (Array, Date) to the ES6 ones, where it's _not_ (Map, Set).  They kept the Object.prototype.toString behavior, which made sense for Array and Date but is nonsense for Map and Set.
 
I can't do much about that at this point, but I don't think we should let this author-hostile mistake infect the entire web platform.  Yes, the proposed PR gives a behavior that is really easy to spec and implement, but also I suspect one that no sane author would never suggest.  This is the tail wagging the dog.

In an ideal world, ES would have allowed preserving the existing long-standing behavior of browsers.  But the ES committee allowed theoretical purity to stand in the way of speccing something useful, so I guess we have to make do with the @@toStringTag mechanism.  We can still use that to create behavior that is at least sane in the common case, by using an accessor @@toStringTag property on DOM prototypes.

I should note that the argument that this can or should be decoupled from branding detection is very weak from my point of view.  Given the brokenness of instanceof on the web, toString behavior is _the_ go-to brand detection mechanism on the web right now, and we have no replacement.  If we had one, and had been evangelizing it for a while, this behavior change would still be somewhat author-hostile, but at least we would be able to point unhappy authors to the other alternative.  As things stand, it looks like we're just trying to take away any chance for authors to be able to do brand detection.

I should note that ES itself has these problems, and people keep bringing this up, and TC39's official answer for brand detection is "yeah, find something that does brand checks and is side-effect-free and check whether it throws".  Which is quite unintuitive, author-hostile, and not even guaranteed to work on all IDL types (e.g. there might not be anything side-effect-free).  I have yet to meet anyone who thinks that brand-detection this way is a good idea, outside TC39...

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/pull/357#issuecomment-298464776