Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)
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>
>>> 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.
So first thing to try is breaking compat on the answer to 3. I will see
More information about the es-discuss