ES4 stable draft: object initializers

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ES4 stable draft: object initializers

Lars Hansen-3
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.

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss

object-literals.html (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Waldemar Horwat
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?


    Waldemar
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Waldemar Horwat
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.

    Waldemar
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

liorean
On 16/04/2008, Waldemar Horwat <[hidden email]> 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.
--
David "liorean" Andersson
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Jeff Dyer
In reply to this post by Lars Hansen-3
Re: ES4 stable draft: object initializers 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”.

Jd


On 4/10/08 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.

--lars

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss


_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Jeff Dyer
In reply to this post by Waldemar Horwat



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.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 stable draft: object initializers

Lars Hansen-3
Presumably that would be __proto__ so that we would not be gratuitously
incompatible with Firefox.

--lars

> -----Original Message-----
> From: Jeff Dyer
> Sent: 17. april 2008 16:12
> To: Waldemar Horwat; Lars Hansen
> Cc: [hidden email]
> Subject: Re: ES4 stable draft: object initializers
>
>
>
>
> 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.
>
> Jd
>
>
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Brendan Eich-2
In reply to this post by Jeff Dyer
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.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Erik Arvidsson
2008/4/17 Brendan Eich <[hidden email]>:
> 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.

--
erik
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Jeff Dyer
In reply to this post by Brendan Eich-2
Re: ES4 stable draft: object initializers


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.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: ES4 stable draft: object initializers

Lars Hansen-3
Re: ES4 stable draft: object initializers
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.
 
--lars


From: Jeff Dyer
Sent: 18. april 2008 06:34
To: Brendan Eich
Cc: Lars Hansen; [hidden email]
Subject: Re: ES4 stable draft: object initializers




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.

Jd

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Jon Zeppieri-2
In reply to this post by Lars Hansen-3
On 4/10/08, Lars Hansen <[hidden email]> 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 ... } }

-Jon
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Brendan Eich-2
In reply to this post by Erik Arvidsson
On Apr 17, 2008, at 5:15 PM, Erik Arvidsson wrote:

> 2008/4/17 Brendan Eich <[hidden email]>:
>> 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.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: ES4 stable draft: object initializers

Brendan Eich-2
In reply to this post by Lars Hansen-3
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:

http://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. */}.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss