+1. I was always glad that the shape argument had seemed to lead to the same conclusion and I am sad to see it go. But my reason for supporting the check was to catch errors early for strict object literals. I don't much care what happens here if the object literal is sloppy.
On Tue, Nov 12, 2013 at 3:55 AM, Andreas Rossberg <[email protected]>wrote: > On 26 October 2013 04:49, Allen Wirfs-Brock <[email protected]> wrote: > > The plan has been that runtime validation would be performed for any > object > > literals containing computed property keys and the current spec. draft > > contains pseudo code for doing the checks. However a bug report > > (https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out an issue > with > > the current spec. For example, the current spec. throws an error on: > > > > ({get a() {}, > > get ["a"]() {} > > }); > > but not on: > > ({get ["a"]() {}, > > get a() {} > > }); > > > > Basically, it isn't sufficient to only check for an already defined > property > > key when processing property definitions that contains a computed key. If > > any computed keys exist the checking has to be done even for the > definitions > > that have literal property names. And it isn't sufficient to just > consider > > the property keys and the data/accessor property distinction, the > validation > > also has to take into account the syntactic form of the definition and > > whether or not strict mode applies.. > > > > It turns out that even in pseudo code, this is a fairly complicated set > of > > runtime validation rules to apply. I'm having a hard time convincing > myself > > that the runtime computational and meta data costs of this dynamic > > validation is justified. It costs too much and the actual benefit is > pretty > > small. > > > > ***For that reason, I propose that we drop this runtime validation of > object > > literals (and class definition). We would still have the static > validation > > and early errors for property definitions that don't have computed keys. > But > > anything that makes it past those checks (including all property > definitions > > with computed names) are just processed sequentially with no duplicate > name > > checking.*** > > I'm not convinced. I think the check is useful, and erroneous > situations like this going unnoticed could lead to really nasty > surprises. > > Is their a chance that the check could be factored into the > DefineProperty meta operator? I.e., just like the strict mode flag it > also has a flag saying whether redefinitions are allowed? > > > What about predetermining the "shape" of literal objects that include > > computed property keys? > > > > One of the reason for the dynamic checks was the desire to preserve the > > characteristics that allowed an implementation to look at an object > literal > > and statically determine exactly how many own properties the resulting > > objects would have. The hope was that an implementation could still > > determine an intended shape and that the dynamic checks would guarantee > that > > the actual constructed objects conform to that predicted shape. If we > drop > > the dynamic checks we loose that shape guarantee. > > > > I think this ability to predict an intended shape was probably a > committee > > pipe-dream. Consider this function: > > > > function makeObj(a,b,c,d,e) { > > return { > > get [a] () {}, > > get [b] () {}, > > set [c] (v) {}, > > set [d] (v) {}, > > set [e] (v) {} > > } > > } > > > > The object returned by this function might validly have 3, 4, or 5 > > properties. The is no clearly intended shape to try to guarantee. > > Fair enough, I always considered the shape argument a red herring. > > On the other hand, I think what the above primarily demonstrates is > that get/set was a regrettable choice of syntax. :) > > /Andreas > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
