Mark S. Miller
erights at google.com
Thu Feb 9 18:11:51 PST 2012
On Thu, Feb 9, 2012 at 4:11 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>
> I've written a draft __proto__ specification for the working draft of the
> ES6 spec.
> Just the __proto__ part of the spec. can be seen here:
Hi Allen, regarding B3.1.1 and B3.1.2, I was afraid it would have an effect
on the spec like that. This is a hack which crufts up the working of some
of the most basic operations of the language. For those who would try to
prove properties about programs in the language, this extra complexity is
where they can least afford it. But given the behavior you're trying to
specify, I don't see how to do better than this.
As I wrote earlier in response to Herby:
On Mon, Jan 30, 2012 at 7:13 AM, Mark S. Miller <erights at google.com> wrote:
> -1 to adding yet another attribute to the object model (expanding it 16%)
> unless the payoff is huge.
Your UnderscoreProtoEnabled wouldn't seem to be as bad as that, since it is
an internal property rather than an attribute. But it is an internal
property effecting the behavior of the default [[Get]], [[Put]], and
[[DefineOwnProperty]], whose semantics are already way more complex than
If we can't indeed specify this behavior in a less invasive way than this,
then I would rather see us adopt the approach advocated by Gavin and
written up in the current strawman: The dynamic semantics is fully
explained by a non-magical accessor property, that appears to be an
accessor property, and whose setter is a genuine first class function with
the exclusive ability to mutate the [[Prototype]] internal property of
extensional objects in its frame. This approach is much much cleaner. It is
more permissive, as Brendan points out, but not in a way that needs to harm
Regarding B3.1.3, in step 3 of the first algorithm, where does P come from?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss