Brendan Eich wrote:
Erik Arvidsson wrote:
On Mon, Oct 1, 2012 at 3:30 PM, Brendan Eich<[email protected]>
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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
