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

> It's not possible to align with 3/4 implementations without changing the ECMAScript spec.

In edge cases, sure, but in the common case, it's possible.

> I'd appreciate a little more civility

My apologies; I will try.  None of this is meant to be personal, obviously!

> Object.prototype.toString is already not a brand detection mechanism.

Not in the face of hostile code, sure (but neither is anything else in the platform, including Array.isArray, which could have been overridden).  But for things like catching inadvertent mistakes, or just checking what sort of objects you're dealing with when debugging, it's a lot better than nothing.

> Especially since such objects (interface prototype objects) are so very rarely passed around to functions that might try to branch on brand-detection

Just to check, is the "very rarely" based on gut feeling or data?  [LenientThis] exists in IDL precisely because of libraries passing some prototype objects around to places that then _didn't_ brand-detect... while other places did, so we didn't have to add LenientThis too widely.

> The issue here is that we haven't seen sufficient author demand for unforgeable brand detection.

Sure.   I don't think anyone is asking for unforgeable brand detection in the "works in the face of hostile code" sense.

> As opposed to simply usually-working brand detection

I guess the disagreement is about what "usually" should mean.  Again, no one is asking for brand detection in the face of hostile code, and it's _very_ hard to provide anyway.  But brand detection that catches simple mistakes in normal code (e.g. passing in a prototype when an instance is expected) is something some developers do want.  That's why you end up with various people using `Object.prototype.toString.call`, or branching on instanceof checks, etc...  My experience has been that when the facilities to do such detection exist (e.g. in Firefox extensions or Firefox front-end code), people easily come to rely on them.  The times when we've made them go away there was all sorts of unpleasant surprise on the part of the authors of various JS bits.

I've definitely heard a number of people be surprised when they inspect an object in Chrome's developer tools and discover that while it says "Document" it's not actually a Document instance.  And yes, I'm aware that developer tools don't have to use any of the stuff we're discussing here.  This is merely a data point about what people expect or don't expect...

> But a proposal for such facility needs to go through the normal standards process for a dedicated feature, where we present use cases and discuss APIs and get multiple-implementer commitment to implement. 

Yes, I agree.  We should do this.  We've been saying for years we should do this, but it keeps getting shot down for ES types in TC39 because brand detection is seen as an anti-pattern there and in IDL discussions because it's been nearly impossible to get people to comment with anything other than "let's defer this to TC39; this should be defined for all types in the platform".  So we keep going around in circles.  :(

> I don't think it's appropriate to repurpose JavaScript language hooks (hasInstance or toStringTag) to start working differently than they normally do, as a way of getting this API you want shipped.

Just to be clear... the toString behavior under discussion (the one you're proposing the non-Chrome engines remove) is at least 16 years old.  I don't know how much older, because I wasn't involved in browser development before then, and I don't have any Netscape 3/4 or IE 3/4/5 instances around to test them.   If I had to take a guess, this has been the behavior ever since there was a DOM at all.  The instanceof behavior in Firefox is of similar vintage, I'm pretty sure.

So we're not talking about non-Chrome browsers hackily changing the behavior of toString to fulfill this branding-detection use case all of a sudden.  We're talking about a _very_ longstanding behavior of pretty much every browser (and until at least 2008, _every_ browser) that you think should be changed.  I respect and understand your arguments for changing it, but I think we should have a migration path for people who rely on the existing behavior.

> I admit Chrome was not a good citizen at the time you added these

I didn't add them, per above.  They've been around "forever" in web terms, as browser behaviors.  I agree that in spec terms the vintage is more recent.

I am _extremely_ leery of changing behavior that is almost certainly older than some of the people now working on web browsers, that I know based on past bug reports people are currently depending on or trying to depend on, without providing them with a migration path, at least.

-- 
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-298485125