An "extend" operator is a natural companion to <|

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jul 19 16:33:15 PDT 2011


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


More information about the es-discuss mailing list