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

> Why are we aligning with 1/4 implementations, and not 3/4?

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

> I suspect one that no sane author would never suggest.

I disagree with that, as a sane author. I like having toString behavior inherit prototypically like every other behavior.

In general I find the tone of your post a little insulting, both to me as a web developer, and to me as a TC39 member, and to me as someone who works on a browser who finds this version more reasonable. I'd appreciate a little more civility.

I also don't think authors are nearly as concerned as you are with whether this one edge-case returns XPrototype or X; see below.

>  As things stand, it looks like we're just trying to take away any chance for authors to be able to do brand detection.

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

```js
const x = {
  [Symbol.toStringTag]: "Node";
};

Object.defineProperty(document, Symbol.toStringTag, {
  value: "NotDocument"
});
```

Now, `x` will "brand detect" as a Node, and `document` will "brand detect" as a NotDocument.

Given that Object.prototype.toString is already not a reliable brand, I don't think allowing one more class of object through such checks is a problem. Especially since such objects (interface prototype objects) are so very rarely passed around to functions that might try to branch on brand-detection.

> I should note that ES itself has these problems, and people keep bringing this up, and TC39's official answer for brand detection is

The issue here is that we haven't seen sufficient author demand for _unforgeable_ brand detection. (As opposed to simply usually-working brand detection, such as that provided by `x.constructor.name` or `Object.prototype.toString.call()`.) You clearly think it's important, presumably for the web applications you are writing.

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

I admit Chrome was not a good citizen at the time you added these, in that we didn't raise our objections in a timely manner. But I hope you can forgive that and collaborate with us now.

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