Proposal: Object.defineProperty shorthand

Allen Wirfs-Brock allen at wirfs-brock.com
Tue May 31 14:25:09 PDT 2011


I really don't see great value in trying to use this technique to set attributes for properties created via direct assignment.  The syntax issues are large and assuming that we are able to provide attribute flags in both object literals and class declaration I just don't see that many cases where creation by assignment is will be needed.


On May 31, 2011, at 12:18 PM, Brendan Eich wrote:

> On May 31, 2011, at 11:52 AM, Sean Eagan wrote:
> 
>> I still like the syntax proposed at the beginning of the thread the best.
> 
> I like # for non-configurable, ! for non-writable, and ~ for non-enumerable too. All prefixes. But not for assignment expressions as I think you showed -- only in object initialisers and classes.

This is as plausible as using ! for non-configurable as I had proposed.  It really comes down to alignment with other uses of #.  It is pretty easy to make a logical association between this mapping of symbols to meanings.   However, it would be pretty cryptic  if we every needed to add a fourth or fifth attribute systems.


> 
> 
>> I know the concern from TC39 at the May meeting with object literal
>> extensions [1] was that the syntax was "punctuation soup".  Does
>> co-locating all 3 characters as a single prefix help with this?  I
>> think it would have to be single characters for each attribute, if you
>> use the full names you are hardly gaining enough conciseness to make
>> it worthwhile.
> 
> Agreed. We've swerved from a verbose proposal at the March meeting, where Allen gamely tried to reuse existing keywords, then generalized and regularized to spell everything out; back to the terse punctuator approach we saw at May, but with := after the property name for read-only.
> 
> Using prefixes only seems strictly better than !~ before and := after. Also, using # for non-configurability lines up with hash-arrows or hash-functions as frozen/joined, records, and tuples. Although in your proposal # means only non-configurable, not also non-writable.

concise method properties may create a problem for  # meaning non-configurable.  the object literal proposal currently allows:

var foo  ={
     bar() { }
};

as short hand for:
var foo = {
   ~bar: function bar() {}
}

but if 
  #bar() {}
or
 #baz()->{}
is valid in general expressions, then what is the meaning of:
var foo = {
   #bar() {},
   #baz()->{}
}

is it:

var foo = {
   #bar: #bar() {},
   #baz: #baz()->{}
}
or
var foo = {
   bar: #bar() {},
   baz: #baz()->{}
}


> 
> A Unix-y (ls(1) inspired) mid-point might be to use strings:
> 
> var foo = {
>   {"!c!e!w"} high_integrity: 42,
>   ...
> };
> 
> or even
> 
> var foo = {
>   {"!(cew)"} high_integrity: 42,
>   ...
> };
> 
> but now there's a little language encoded in the string. We would need some rules to future-proof the design. At least this would be more concise than the most-verbose proposal.

but I don't think it would make those who object to "punctuation soup" any happier 

> 
> My view is that there's no middle way. We should take the punctuation soup hit, using the right punctuators, to make up for the verbosity tax of ES5's property descriptors. # for !c, ~ for !e, and ! for !w seem best at the moment.


I agree

Allen



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110531/1ed5209d/attachment-0001.html>


More information about the es-discuss mailing list