On Nov 12, 2011, at 1:20 PM, Axel Rauschmayer wrote:

> More:
> 
> function Point(x, y) {
>     this.{x,y};
> }

Ok, maybe. But


> function Monster(name) {
>     this.{
>         name: name,

just name here should do, not name: name -- right?


>         @strength: 10,
>         @age: 0
>     };
> }

Someone had to declare private strength, age; first.


> // namespace exists in multiple files (possibly less relevant with modules)
> namespace.{
>     function1() {
>     },
>     function2() {
>     }
> }

This caused a double-take because of the leading 'function' names distinguished 
only by trailing "1" vs "2". There is something to the complaints about method 
definition syntax being too terse in certain applications. Just changing to 
method1 and method2 helps, though.

Maybe that's part of the whole Grawlix thing. o.{m(){}} vs. Object.extend(o, 
{m: function(){}}). The latter is JS we've known for many years.

/be


> 
> 
>>>> If we do classes, what .{ use-cases remain?
>>> 
>>> The operator allows you to use object literals (including all of the 
>>> niceties that will be introduced in ES.next) where you previously had to do 
>>> multiple assignments. It’s especially nice for adding things to prototypes. 
>>> For example:
>>> 
>>>   function Person(name) {
>>>       this.name = name;
>>>   }
>>>   Person.prototype . {
>>>       describe() {
>>>           return "Person called "+this.name;
>>>       }
>>>   };
>> 
>> That's a good point -- it preserves .constructor, unlike assigning a fresh 
>> object literal to Person.prototype.
>> 
>> /be
> 
> -- 
> Dr. Axel Rauschmayer
> a...@rauschma.de
> 
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
> 
> 
> 

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

Reply via email to