On Jan 29, 2012, at 3:25 PM, Gavin Barraclough wrote: > On Jan 29, 2012, at 11:36 AM, Allen Wirfs-Brock wrote: >> Other standard properties that have accessor like characteristics but look >> like data properties: >> >> array element properties >> array length property >> string character element properties >> argument object elements >> the "caller" property of function objects (see 15.3.5.4) > > The special handling for setting array length and and numeric properties fits > well with the spec's existing division of labour between the [[Put]] and > [[DefineOwnProperty]] algorithms, and is well encapsulated. [[Put]] provides > a simple set of rules for determining whether a [[DefineOwnProperty]] will be > called on the base of the access, or whether a setter will be called on the > prototype chain. The 'magic' here is constrained to certain objects > overriding the [[DefineOwnProperty]] trap (e.g. 15.4.5.1). > > It seems that any 'magic' to make __proto__ work in the proposed fashion > could not be constrained to a [[DefineOwnProperty]] trap for the Object > prototype, since if __proto__ is a data descriptor [[Put]] will trigger > [[DefineOwnProperty]] trap on the base of the access. Any special handling > would either need to also rework [[Put]] to cause the special __proto__ trap > to be triggered, or would need to be worked into Objects's > [[DefineOwnProperty]] (8.12.9). Any special handling in 8.12.9 would need to > be non-trivial, since setting an object's __proto__ property would mean > re-inspecting the prototype chain to see whether the nearest __proto__ was > the magic data descriptor. Either way seems unnecessarily complicated, and > much less well encapsulated than Array's special handling of > [[DefineOwnProperty]].
There are no rules that constrain [[Put]] in this manner you are suggesting. > > I just don't see why we would want to muddy up some core mechanisms of the > object model, making them more difficult for users of the language to > understand, for the non-benefit of making __proto__ appear to be something > that it isn't. It just seems like a bad idea wrapped in a bad idea to me. Well, arguably the existence of __proto__ is what muddys up some of the core semantics of the object model. I would specify it as a modification to the normal [[Get]] and [[Put]] behavior that special cases on the property key value "__proto__". That special case (of [[Put]]) would not call [[DefineOwnPropertry]]. It would include check the prototype chain but that is part of the proposed semantics. This seems like a perfectly reasonable way to specify this. As __proto__ does indeed affect the property access semantics for every object. Of course, I'm only talking specification. How you accomplish it in your implementation is up to you. There are other, alternatives. If we were willing to only define obj.__proto__ and exclude obj["__proto__"] I could specify it in 11.2.1 as a special case semantics of dot property access notation and have to extend any of the internal methods. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
