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

OK, this is turning into a good discussion :). I think there are two main topics:

---

(1) In aligning Web IDL with modern ECMAScript, do we define [Symbol.toStringTag] as (a) on the prototype only, with value "X"; (b) as a getter on the prototype, which branches and returns either "X" or "XPrototype"; (c) as a data property on both the prototype ("XPrototype") and every instance ("X").

Note that if we choose anything but (a), we have zero browsers complying with the spec, whereas (a) at least has one browser.

Chrome believes the answer should be (a), for the following reasons:

- It is more consistent with ECMAScript built-ins
- It is simpler to make performant (unlike (b)) and memory efficient (unlike (c))
- We have been shipping it for over a year with no reported compatibility issues

> Just to check, is the "very rarely" based on gut feeling or data?

This is based on a gut feeling. Would it help if we provided data? Perhaps we could use-counter how often interface prototype objects are passed to Object.prototype.toString.call(). If we do this, we should pre-commit to a threshold below which you think it'd be OK to change to behavior (a).

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

Our feeling is that the migration path should not be necessary as a prerequisite for changing the behavior, since we have not seen author demand for a brand-checking facility that excludes interface prototype objects. Specifically, we have seen no reported issues where people were frustrated by Chrome's behavior change. Similarly, we were hoping to show by shipping that there's no need to be so leery of the change.

----

(2) The topic of adding a general brand-detection API

Although our starting position is skepticism about the value of such an API---as you say, we disagree on the value of "usually"---we're definitely willing to discuss it. We should have this discussion.

It's pretty clear that waiting on TC39 is not the right approach. Whatever we do could either work for platform objects only, or could special-case the ECMAScript built-ins, like StructuredSerialize (née structured clone) does. There's a path here; we can do it.

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