Re: computed property keys and ES5 duplicate rule enforcement
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
Re: computed property keys and ES5 duplicate rule enforcement
+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 rossb...@google.comwrote:
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
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: computed property keys and ES5 duplicate rule enforcement
On Oct 25, 2013, at 7:49 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
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.***
Yep, I fully agree. And I especially appreciate what you say below:
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.
Amen.
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.
The shape predictability concept has never really been defined clearly, and
this is a good demonstration of why it's fishy.
Anyway, agreed 100%. It's worth revisiting at the November f2f.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
computed property keys and ES5 duplicate rule enforcement
ES5 introduced several rules regarding duplicate in property definitions in an
object literal. The rules are roughly:
You can use the same property name in both a data property definition and
an accessor property definition
You can't define more than one get accessor for a given property name
You can't define more than one set accessor for a given property name
In strict mode, you can't have multiple data property definitions for a
given property name
These rules we designed such that they could be statically checked and reported
as early errors.
These rules also need to be expanded to deal with new property definition
forms. For example, just like you can't use the same name in both a data
property definition and an accessor property definition (in any mode), it
should also be illegal to use the same name in both a data property definition
and a concise method definition or have two concise methods with the same name.
The addition of computed property keys in object literals means that these
conditions cannot be fully statically checked if any of the property
definitions in an object literal has a computed property key.
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.***
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.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
