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

Brendan Eich brendan at mozilla.org
Mon Oct 1 16:26:22 PDT 2012


Brendan Eich wrote:
> Erik Arvidsson wrote:
>> On Mon, Oct 1, 2012 at 3:30 PM, Brendan Eich<brendan at mozilla.com>  
>> wrote:
>>> Erik Arvidsson wrote:
>>>> I'm with Allen, Andreas and others that the craziness needs to stop.
>>> Which craziness?
>>
>> That the prototype of the constructor needs to be a special case of
>> the instances created by the constructor.
>>
>> Today, both "new Date" and "Date.prototype" are date objects. I think
>> this just makes things more complicated for no apparent gain.
>
> Yes, and it makes that side channel that vexed Mark and SES (Caja).
>
> Can we change incompatibly? Rick just asked what code relies on 
> builtins being firstborns. No one relies on degenerate firstborns 
> except by toString "tag testing".

Just to be super-clear:

1. I agree the built-ins do something irregular and not expressible in 
the language in making C.prototype for built-in class C a firstborn that 
may or may not be fully constructed, that has a [[Prototype]] != itself 
(of course, but different from every other instance of C), etc. This is 
a botch to fix. However:

2. We could change C.prototype to be an Object instance with the right 
[[Prototype]] and 'constructor', minimally. That's what CoffeeScript and 
the best-practice Domenic cited do and it neatly avoids any hidden 
mutable state. C.prototype is not a constructed B in the case of class C 
extends B, but that must be the case if we are to avoid any B that 
*creates* mutable state directly on the |this| being constructed.

3. We could go further and set @@toStringAtom in C.prototype to have 
value "C". That lines up with 'constructor' but of course lies its head 
off since C.prototype is not actually a C instance.

My current favored answers for all constructors, built-in or not, 
phrasing the question as "Should we fix/do it?" 1: y, 2: y, 3: n.

If we can't break compat by making built-ins answer 3: n, then I would 
want uniformity: 1: y, 2: y, 3: y. This is where we may part company -- 
I can understand wanting to split the answer depending on legacy vs. 
non-legacy.

So first thing to try is breaking compat on the answer to 3. I will see 
about that...

/be


More information about the es-discuss mailing list