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

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


On Tue, Oct 2, 2012 at 10:13 AM, Brendan Eich <brendan at mozilla.com> 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
substitute.



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



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121003/5bf5f4bf/attachment.html>


More information about the es-discuss mailing list