On 6/3/16 8:05 PM, smaug wrote:
Why is the change being done? Why do we think @@toStringTag stuff is a
good thing?
@@toStringTag is the mechanism ES6 added to provide a hook for
controlling what Object.prototype.toString does so other specs (like
DOM) don't have to monkeypatch ES to get custom
Object.prototype.toString behavior. I _believe_ the plan is for
SpiderMonkey to implement it and then remove the current setup (which
uses class names).
There seems to be desire from various people to remove the
monkeypatching in the WebIDL spec, and that means moving to
@@toStringTag instead.
Now even with @@toStringTag there are two possible behaviors: it can be
a value property, or it can be an accessor that does something smart
with the "this" value. I would be quite fine with the latter, actually;
the problem is convincing the other UAs (and in particular Chrome) that
this is the right direction to go. I personally don't have the energy
to fight about this, but if someone else cares they are more than
welcome to...
IMHO, the current Gecko behavior for toString makes more sense than the
proposed one.
I totally agree. I also think that moving from everyone having interop
to the situation we have now is ridiculous. Wish I could have convinced
the Chrome folks of that.
Not really objecting anything here, but just wondering why this kind of
change is being done.
See above.
W3C bug doesn't quite capture the reasoning here.
There's not much reasoning for the specific change to align prototype
and instance toString values other than Chrome unilaterally changing
behavior, really.
As I said, we could push back on this, make @@toString an accessor on
DOM prototypes, and figure out what semantics to define for it, exactly,
particularly when the passed-in object is neither the prototype
@@toString is defined on nor an instance of the corresponding interface.
Some specific things that would need deciding:
1) What happens when the Node.prototype.@@toString getter is invoked
with an HTMLDivElement as the `this` value? Should it return "Node" or
"HTMLDivElement" or "Object" or throw? Or something else? Similar
questions for HTMLDivElement.prototype as `this`.
2) What happens when the Node.prototype.@@toString getter is invoked
with an XMLHttpRequest (an IDL object not implementing Node) as `this`
value? Should it return "Node" or "XMLHttpRequest" or "Object" or
throw? Or something else? Similar questions for
XMLHttpRequest.prototype as `this`.
3) What happens when the Node.prototype.@@toString getter is invoked
with some random non-DOM (an IDL object not implementing Node) as `this`
value? Should it return "Node" or "Object" or throw? Or something else?
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
