On Feb 9, 2012, at 6:11 PM, Mark S. Miller wrote: > On Thu, Feb 9, 2012 at 4:11 PM, Allen Wirfs-Brock <al...@wirfs-brock.com> > wrote: > 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: > http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Amagic_proto_property&cache=cache&media=harmony:draft_proto_spec_.pdf > > > > 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.
I doubt that you will find anybody who will argue that the original functionality was ever anything more than a hack. But the I think this specification is pretty close to the minimum necessary to specify it. Somebody trying to prove properties about program certainly could attempt to transform it into an equivalent specification. > > As I wrote earlier in response to Herby: > > On Mon, Jan 30, 2012 at 7:13 AM, Mark S. Miller <erig...@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 we'd > like. and [[Delete]]. And its not a property, just a piece of internal state global state. Also, I made sure to make all the changes to these key internal methods as prologues to the normal definitions. > > 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 security. I would expect Gavin's approach to ultimately be even worse than mine from a semantic analysis perspective. It expose (via Object.getOwnPropertyDescriptor) functions that have the ability to mutate any object's [[Prototype]] property and one those functions are exposed they can be installed as methods or explicitly called at any time. I think that tame them is likely to have even greater impact than what I have done. Certainly, for the ES5 language level (which is what my current spec. addresses) there is no way to talk about frames or the association of one of these functions or any other object with a frame. With my approach there is no need to match the proto mutator function's frame with the target object's frame, because there is no mutator function. Finally there is the object literal issue which was not address by the original wiki proposal. > > > Regarding B3.1.3, in step 3 of the first algorithm, where does P come from? oops, P should be propId.name also in step 5 of the second algorithm Allen > > -- > Cheers, > --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
