On Jul 19, 2011, at 3:45 PM, Brendan Eich wrote:

> On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
> 
>> Also, why ; instead of , like in object literals
> 
> We've been over this before: because methods have braced bodies that should 
> not require either ; or , to be separate from adjacent methods. A class body 
> is not an ObjectLiteral grammatically. We do not want to require
> 
>   class C {
>     m1() {...},
>     m2() {...},
>     m3() {...}
>   }
> 
> when top level functions do not need any such comma separation.
> 
> 
>>  (alternatively could we allow use of ; as a separator in object literals).
> 
> No one is looking for that extension.
> 
> 
>>  It seems desirable to have consistency of property definitions between 
>> object literals and class declarations.
> 
> I don't agree. A class body is not an object literal, even if the method 
> syntax is very close to the proposed ES.next method-in-object-literal syntax. 
> Trying to make a class body be an object literal imposes ugly, undesirable, 
> and likely-to-be-forgotten extra separator or even terminator punctuation (; 
> or,  -- doesn't matter).

Actually, I'm trying to explore going the other direction.  What would it take 
to allow object literals to use the same syntax as class declarations for the 
things that they have in common. 

> 
> Method bodies are braced and, like function declarations in ES1-5, do not 
> require gratuitous ; or , termination or separation from following source 
> elements.

but you are not also arguing for eliminating the requirement for a , after a 
method property in an object.  Right?

 let c = {
   m1() {...}
   m2() {...}
   get g() {...}
   set g() {...}
   m3() {...}
}
   
If this is correct, I don't see why you are making the argument for one 
construct and not the other.

> 
> This means data property declarations in a class *do* need some kind of 
> termination, and the obvious candidate for parallelism with function 
> declarations is the semicolon.
> 
> From this, I concede that data property declarations in a class should not 
> try to look like property assignments (key: value) in an object literal.

Object literals and class declarations are very similar in some respects and it 
seems likely that developers will be refactoring one to the other fairly 
routinely.  The more different the common elements are the most difficult that 
refactoring will be.  It also increase, the leaning burden to have different 
ways to express the same concept that must be used in different contexts.

Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to