On 26 October 2013 04:49, Allen Wirfs-Brock <al...@wirfs-brock.com> 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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
