W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2016

[Bug 28244] Requiring @@toStringTag on instances may have performance implications

From: <bugzilla@jessica.w3.org>
Date: Fri, 02 Sep 2016 17:39:39 +0000
To: public-script-coord@w3.org
Message-ID: <bug-28244-3890-nszPyqFPvY@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244

--- Comment #14 from Boris Zbarsky <bzbarsky@mit.edu> ---
> Per comment #8, Boris doesn't quite agree

Comment 8 was about what I'm doing (nothing, partly because I don't have time
to pursue a change here in the face of probably reasonable opposition and
partly because I have 0 interest in making changes that I will then have to
revert because other UAs don't follow), not what I'm thinking.

If you want to know what I'm thinking...

> - It matches the ES built-ins

I think, personally, the ES built-ins are broken.  The setup kinda sorta made
sense for the ES3 builtins where the prototype was really an instance too
(Array, Date).  It's pretty nonsensical, imo, for the new built-ins ES6 adds
(Map, Set, Promise, etc) where all the things you might want to do with an
instance throw if you do them with the prototype.  Now I'm obviously not going
to change TC39's mind at this stage in the game, but I think they made a
mistake here.  The only saving grace is that at least Map.prototype instanceof
Map tests true by default.  But in a multi-global world instanceof is just
broken, so you end up with Array.is (but refusals to add it for anything else)
and people being told they should not worry about validating their inputs and
instead just deal with exceptions if/when they arise.  Except they don't, and
you get broken websites when some idiot library walks the object graph and
suddenly finds an object it did not expect; run into that a number of times as
browsers have added new features.  So people who want to avoid that pitfall and
want to be careful use Object.prototype.toString to see what they're really
working with, since instanceof is useless for that purpose.  Of course with
@@toStringTag this method of telling what you have might also become useless...
we'll see.

I know this is getting rather far afield, but the theory of how people write JS
and the practice of how at least a large minority do so are very much at odds,
and it's the theory that's been driving TC39 decisions...  As a result, I'm
biased to be somewhat sceptical of adopting those decisions wholesale in other
parts of the web platform, particularly when that involves changing
long-standing behavior; it's bitten us before when we have.

>- It fits better with JavaScript's prototypal inheritance model (now that toString behavior is something that prototypally inherits)

I don't see how using an accessor property fails on this bullet point, for what
that's worth, any more so than any other thing living on the prototype that
only works on instances; ES6 is littered with that sort of stuff, as are the
IDL-defiend parts of the web platform.

>- It's simpler

Granted.  If we had no history here and had some other way of doing brand
checking, I don't think anyone would even dream of suggesting that we should
use Object.prototype.toString as a brand checking mechanism.  Objectively
speaking, it is, of course, daft.

>- It's possibly more performant (although a sufficiently smart optimizer could probably equalize them)

Yes on both counts.  I question the performance sensitivity of
Object.prototype.toString on the level we're talking about here, btw; just the
string concatenations required for it already involve a bunch more work than
either option here, I expect.

>- It's very likely to be web-compatible given that it's been shipping in Chrome for several releases

Maybe you meant this is the part I don't agree on?

My experience is that in today's market Chrome can get away with breaking sites
when other browsers cannot; people will work around Chrome issues and just
leave their sites broken in other browsers.  Often enough the workaround
involves sniffing for Chrome and doing something different there, so even if
other browsers implement exactly what Chrome does the site will _still_ be
broken in them.  This is unfortunate, but it does mean that "Chrome shipped it"
is not as useful an indicator of web compat as it could be.  It's better than
nothing, of course, which is why this discussion is happening at all.

I, personally, happen to think this is web compatible enough, that it just
screws over people trying to be careful, and that most people writing code on
the web are not being very careful in this way and hence will be unaffected.  I
was not able to sell others within Mozilla on this viewpoint, though, at least
not with the limited amount of effort I put into it.

> Perhaps we could get other engines to comment? 

That would be the most useful thing, yes.

P.S. Note that Chrome's devtools most definitely display event instances and
Event.prototype differently; they are clearly making a branding decision
somewhere in there.  How they make it given the relative paucity of public
facilities for this sort of thing, and why we want to deny web pages the
ability to make similar distinctions, is an interesting question.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Friday, 2 September 2016 17:39:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 2 September 2016 17:39:48 UTC