Extended Object Literals to review

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Mar 14 09:46:44 PDT 2011


On Mar 13, 2011, at 2:10 PM, Faisal Vali wrote:
...
> In the context of the proposals(*), are the following syntactic
> constructs valid within object initialisers - and what are their
> semantics?
>   1) var toString : const() { ... }
>   2) var toString : function() {... }
>   3) var toString : #() {... }
> 
 I didn't explicitly incorporate any new harmony syntax proposal into my proposal.  This is just to minimize interdependencies among proposals. In general, any new syntactic forms that parses as a AssignmentExpression are allowed to the right of the : (or : const). Give that, according to the currently proposal they would all define a toString property that had the attributes {enumerable: false, writable: true, configurable: true}.  In order to make it a read only property you would have to code:
1c) var toString: const const() { ...}
2c) var toString: const function() { ...}
3c) var toStrong: const #() { ... }

Case 1 presents some parsing issues issues because a parser would have to lookahead to the { before it can determine whether the right had side of the : is a parenthesized  expression with the const property modifier or a const function.
   var c: const (a,b,c,d,e) { }

A someday we will have to start making global design trade-off among proposals to address issues like this.  For example, if we have the #() { } form, then perhaps const() { } will be less necessary.

Or we may decide that  using : const to mean non-writable is too problematic and re-explore some of the other alternatives.

BTW, the reason the proposal creates a non-enumerable, non-writable property as
   var x: const expr,
rather than:
   const x: expr
is because of feedback on earlier proposals asking for the ability to orthogonally define the full complement of properties attributes. So, 'var' became the modifier meaning enumerable: false and ': const' means writable: false.  Another alternative would be have three prefix keys, for example: sealed, const, and var corresponding to configurable: false, writable: false, and enumerable: false.  Eg:

{sealed const var answer: 42}

However, that means that the grammar and users have to deal with all eight combinations of the prefix keywords (in combination with the detail that the property name may itself be one of the keywords). None of this is insurmountable but moving 'const' to the right of the colon simplifies the prefix combinations to four and (to me) seemed more readable:
{sealed var answer: const 42}

Allen





> My initial thoughts are that if valid, (1) would behave the same as 'method'.
> (2) would be a property that is not enumerable, but can be
> over-written (by data or another function).
> (3) would be the same as (2), but with 'pounder' semantics (re: this,
> return, tco etc...).
> 
> But are they valid?  (Or is var confined only to data properties) And
> if not, what was the argument for disallowing the use of 'var' to
> annotate a property name that could be bound to a function.
> 
> Thanks again!
> Faisal Vali
> 
> (*) http://wiki.ecmascript.org/doku.php?id=strawman:obj_initialiser_const:
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list