ES4 stable draft: object initializers
My comments:
The grammar doesn't work:
{meta::prototype:17} can be parsed as either a FieldName or as the meta::prototype production. To make parsing unambiguous you can't allow "meta" to be included in AnyIdentifier (or implement some other similar fix).
Class type discussion:
Do the properties in the literal need to have any correspondence to the members of the class? As far as I can tell, they can be anything.
If a property name in the record type that annotates the literal
What record type? You didn't say that the type has to be a record type here.
If a literal field is annotated by |const| or |var| and the field is also named in the record type that annotates the literal then the type of the property is the type given in the record type, not the type implied by the initial value of the property (see below).
This paragraph is misplaced. Instead, fix the descriptions of const and var below, as they lead to the wrong conclusion in this case without any hints that they're overridden here.
What is the type of fields without a type annotation?
WaldemarThere is also another ambiguity in the grammar:
var {x:y, p:q} = expr;
is both an assignment expression statement and a destructuring variable binding statement.
Waldemar
On 16/04/2008, Waldemar Horwat <waldemar at google.com> wrote:
There is also another ambiguity in the grammar:
var {x:y, p:q} = expr;
is both an assignment expression statement and a destructuring variable binding statement.
An assignment to an object literal seems like total bogus though - LHS of an assignment should be a storage location and not an object. So logically it makes sense only as a destructuring assignment.
The catchall syntax seems heavy handed for the use cases it serves. It introduces new syntax, not just special meaning for meta¹ qualified names, and it is otherwise possible to create object values with catchalls by using classes.
I propose that we remove the productions that begin with ³meta::get², ³meta::set², ³meta::has², ³meta::delete² and ³meta::invoke².
On 4/15/08 4:38 PM, Waldemar Horwat wrote:
The grammar doesn't work:
{meta::prototype:17} can be parsed as either a FieldName or as the meta::prototype production. To make parsing unambiguous you can't allow "meta" to be included in AnyIdentifier (or implement some other similar fix).
I'd be happy if we spelled "meta::prototype" as "prototype" for this use case.
Presumably that would be proto so that we would not be gratuitously incompatible with Firefox.
On Apr 17, 2008, at 4:06 PM, Jeff Dyer wrote:
The catchall syntax seems heavy handed for the use cases it serves.
It introduces new syntax, not just special meaning for ‘meta’
qualified names, and it is otherwise possible to create object
values with catchalls by using classes.I propose that we remove the productions that begin with
“meta::get”, “meta::set”, “meta::has”, “meta::delete” and
“meta::invoke”.
These are wanted by Ajax library hackers, jresig and shaver testify.
Rather than cut a long-standing proposal because a recent evolution
of its syntax (not its substance) led to something problematic, why
not return to the original syntax:
obj = {get *(id) ..., set *(id, value) ...};
If on the other hand, the syntax is heavy either way, but the
substance is valuable because the use-cases are compelling enough to
serve, then we can stick with meta::get, etc.
2008/4/17 Brendan Eich <brendan at mozilla.org>:
These are wanted by Ajax library hackers, jresig and shaver testify. Rather than cut a long-standing proposal because a recent evolution of its syntax (not its substance) led to something problematic, why not return to the original syntax:
Yes, this feature is indeed wanted. The syntax is not that important. There is also a desire to allow these to be defined on an existing object.
On 4/17/08 2:13 PM, Brendan Eich wrote:
These are wanted by Ajax library hackers, jresig and shaver testify. Rather than cut a long-standing proposal because a recent evolution of its syntax (not its substance) led to something problematic, why not return to the original syntax:
obj = {get *(id) ..., set *(id, value) ...};
I¹m trying to recover the notes that record this long standing agreement. The ³meta::get² syntax showed up on the latest proposal based, I¹m guessing, on a discussion at the March F2F. But I don¹t see any mention of catchalls in object intialisers in the notes or proposals on the wiki, or the es4-discuss archives.
If on the other hand, the syntax is heavy either way, but the substance is valuable because the use-cases are compelling enough to serve, then we can stick with meta::get, etc.
I prefer get¹ to meta::get¹ as a ³keyword² and so I suggest we return to the original syntax. I¹ll make a specific proposal for this change once I see what the original syntax is.
I introduced the syntax for catchalls in object initializers based on a comment by David "liorian" Andersson. I am not aware of any prior agreement to have catchalls in object initializers.
I suspect the simple solution here is to allow meta::get etc to be used as property names in an object initializer with a required "const" attribute, and to spec proto as a contextual keyword to set the prototype:
{ const meta::get: function (id) ..., proto: ... }
It removes extra syntax by allowing existing syntax to state the obvious and is backward compatible with Firefox.
On 4/10/08, Lars Hansen <lhansen at adobe.com> wrote:
Here is the third draft, which I have tentatively labeled as stable.
Please note the OPEN ISSUES, the input of everyone on these would be appreciated.
- There is no way to seal the object created by an object initializer, as a prefix 'const' annotation only distributes across the fields of the object and does not imply anything about the object as a whole.
With catchalls, an object could be sealed like this:
{ const x: X, const y: Y, set *(id) { throw ... } }
If the "a prefix 'const' annotation... distributes across the fields" rule were relaxed to say that the annotation distributes across all non-catchall (and maybe all non-getter/setter [?]) properties, then the above could be abbreviated:
const { x: X, y: Y, set *(id) { throw ... } }
On Apr 17, 2008, at 5:15 PM, Erik Arvidsson wrote:
2008/4/17 Brendan Eich <brendan at mozilla.org>:
These are wanted by Ajax library hackers, jresig and shaver
testify. Rather than cut a long-standing proposal because a recent evolution of
its syntax (not its substance) led to something problematic, why not return
to the original syntax:Yes, this feature is indeed wanted. The syntax is not that important. There is also a desire to allow these to be defined on an existing object.
Can you say more about this last sentence? What existing objects
would want meta-programming fixtures somehow added to their
properties? I know, I'm to blame for defineGetter and it has use-
cases that o = {get x() {...}} can't satisfy, but a named getter is
one thing -- a catch-all is different and scarier. Anyway, I'm
interested in details about your use-cases.
On Apr 10, 2008, at 9:05 AM, Lars Hansen wrote:
Here is the third draft, which I have tentatively labeled as stable.
Please note the OPEN ISSUES, the input of everyone on these would be appreciated.
No one has addressed this OPEN ISSUE:
- The meta::prototype facility does not allow 'null' as a value.
I'm already "spoken for" in the stable draft. I did want to add this
information:
lxr.mozilla.org/mozilla/search?string=proto%3A
which shows no one in the cross-referenced cvs.mozilla.org sources
using obj = {proto: null, ...}. I don't have results for other
repositories, or for Mozilla-specific content on the web.
So I'll withdraw the request to allow null, even though the extent to
which it cripples the expressed object is not different in kind from
what you can do with obj = {toString: undefined, hasOwnProperty:
undefined, /* etc. */}.
Here is the third draft, which I have tentatively labeled as stable.
Please note the OPEN ISSUES, the input of everyone on these would be appreciated.