@@toStringTag spoofing for null and undefined

[Allen Wirfs-Brock]

On Jan 21, 2015, at 6:19 AM, Domenic Denicola wrote:

> I’d urge us to be more cautious about throwing away, or postponing, the solid win that is @@toStringTag. This is something we’ve wanted for a long time.

I was wavering a bit last night [1], but upon further reflection I now totally agree with Domenic above.

O.p.toString has never has and never will be a reliable branding or nominal typing mechanism.  It can, at best, be used as an informal classification tool that can return both false positives and false negatives.  Whether it is usable for this purpose depends entirely on what the developer thinks it is they are testing for and how sensitive that usage is to such false positives/negatives if they actually occurs.

This fact, shouldn't stand in our way of  making O.p.toString more extensible in support of its primary use case, which is generating descriptive strings for different object abstractions. 

It doesn't matter that some developers may continue to use O.p.toString as a classifier.  Or even if they start using the @@toStringTag values for that purpose.  It either works for them or it doesn't.  If they discover it is unreliable, they will stop using it.  If it is reliable enough for their purposes, that's just fine, too.

None of this means that we shouldn't continue to explore a branding or nominal typing mechanisms for ES.  But I'm confident that any mechanism we might agree upon won't be based upon O.p.toString so we shouldn't be worrying about how what we do with O.p.toString might impact any such future design or if those future designs might somehow invalidate  what ES6 did with O.p.toString.  I think I can safely predict that this is not going to happen. Those mechanism should not be conflated and if we developed a future branding design that actually had those problems it would simply be an indication that we don't yet have the right design.

In summary, I think the current O.p.toString spec. is just fine and there is no reason to make any change to it at this time.

Now, let's go process meta for a moment.

Last minute questioning of long standing and well vetted decisions leading to feature drop is a standards committee pathology that we should be trying to avoid. There are very few absolutely right or wrong design decisions in this business. Instead, almost every decision is balancing a complex set of trade-offs and differing opinions/preferences. Finding consensus is hard and it is easy to loose it.  We could reopen the discussion on just about any ES6 feature and discover compromises we made, issues we didn't address, or alternative ways to redesign the feature. If we do this in what is literally the last week before we must be DONE it's probably going to result in a dropped feature (or an unacceptable schedule slip).  And this could happen to any feature. All it takes is one or two individuals standing up and questioning some aspect of the design of a feature.  By doing so at this time, they are implicitly saying, I think we have a fatal problem that must be fixed.  And that's a big deal.

Of course, there may be such problems (the @@create issues were one, but note that issue was raised 6 months ago, not this week). If somebody identifies a truly fatal issues, we need to deal with it.  But at this point in the process each of us needs to be very careful about breaking consensus  on long standing design decisions. Probably a good thing to ask ourselves, before we raise such an issue is "is this a big enough problem that I think it wold be better to slip publication/Ecma approval  by 6 months rather than publish what is already in the spec.

Shipping is winning; worse it better!

Allen

[1] https://esdiscuss.org/topic/tostringtag-spoofing-for-null-and-undefined#content-23 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150121/e4a6a253/attachment.html>