Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

Mark S. Miller erights at
Wed Oct 3 13:20:30 PDT 2012

On Tue, Oct 2, 2012 at 10:13 AM, Brendan Eich <brendan at> wrote:

> Allen Wirfs-Brock wrote:
>> On Oct 1, 2012, at 9:56 PM, Brendan Eich wrote:
>>  Allen Wirfs-Brock wrote:
>>>> We can try to tell ES implementors that they must do certain things in
>>>> order to be in conformance but that really doesn't work for code written by
>>>> users of the language.
>>> You're right, we'd be letting usercode, not just some (benign or malign,
>>> but if malign then game over already) host object, spoof a core language
>>> built-in.
>>> But if we have a solid branding mechanism (like Domado's ideal in latest
>>> browsers? ;-) then that should be used universally and this becomes a
>>> don't-care.
>>> /be
>> Great, but this is really an orthogonal issue from my extensible
>> Obj.proto.toString design.
> I know, but I'm trying to simplify the spec further than you are.
> (Allen and I had a phone call -- thanks to that, better understanding of
> what's at stake.)
> Unfortunately, toString is used as a brand test by old code and SES
> (targeting pre-ES6 browsers). But rather than enshrine this forever, I
> would like to discuss breaking one case slightly in order to have a simpler
> spec.
> The case that the draft spec upholds is
> * New ES6+ browser, old and new script mixing, old script uses
> O_p_toString_call to tag-test and new script uses @toStringTag to spoof.
> I'd like to break this case, allowing old script in a new browser to be
> spoofed by new script using @toStringTag.
> Mark, is this a worry? If so then perhaps we are stuck with the
> complicated Object.prototype.toString in the latest draft.

It is a worry, but my position remains that I am willing to take this
chance iff ES6 has an adequate branding mechanism.

> If not, and I would argue any SES subset must protect its "old script"
> from any spoofing new script, then we should try to unify [[NativeBrand]]
> and @@toStringTag by eliminating use of the former in
> Object.prototype.toString's spec, making the latter the sole extension
> mechanism.

and with a new branding mechanism that a defensive program can feature test
for. In the absence of the feature, it should be valid for a defensive SES
program to assume that ES5 [[Class]] remains a valid brand. We can't have
an interval where the old mechanism is broken and there is no safe

> Allen and I also discussed the plan I intend to try in SpiderMonkey:
> making Date.prototype, Number.prototype, etc. test as "Object" according to
> the O_p_toString_call tag test. We think this should not affect SES or any
> real code (as Oliver postulated).

I agree. And if it does affect SES, we can still fix it. From the SES pov,
this one is easy.

> Comments welcome,
> /be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list