I'm not opposed to the class literal as much as I was trying to think of the most minimal classes that could find some consensus. It seems from the discussion that if no syntax can be agreed on, then perhaps it would have to wait for ES.next.next.
The problem with the class literal syntax that you've turned my proposal into (and similar to many of the other proposals) is that it is yet another form with it's own syntax which must be agreed on and then later understood by developers etc. That may be worthwhile if there are significant benefits, but so far it sounds like nobody can agree on any additional features beyond what I propose other than some syntactic sugar. I would hate to see the whole thing get thrown out, so I guess I would say that maybe what I'm proposing is a backup plan. One of the other things I find appealing about my proposal is that it is very clear that the {}s are for an object literal. That means it's contents are already well defined. At first glance, if I see "class Foo {" I might expect what follows to be like a module or function body. It also unifies the notion of extension to a single operator, instead of prototypes using <| and classes using extend. On the other hand, perhaps we could flip the bit the other way, and unify on "extend" instead of <|. In scala, the is both a "class" and "object" syntax that is kind of similar to the situation we currently have creating objects with object literal notation and class literal notation. In scala, they would be: object Foo extends Bar {...} and class Foo extends Bar {...} Where object Foo defines a single object instead of a class. Perhaps instead of saying: var sub = sup <| {...} We should be using object sub extends sup {...} And then at least we would have some consistency between these similar concepts. I know that <| has more flexibility and other cases beyond this, but I think these are the most common. - Russ On Oct 1, 2011, at 6:20 PM, Axel Rauschmayer <a...@rauschma.de> wrote: >> const ClassName = SuperClass <| { >> constructor(/*constructor parameters */) { >> //constructor body >> super.constructor(/*arguments to super constructor */); >> this.{ >> //per instance property definitions >> } >> } >> method1(){ return super.method1(); } >> method2(){} >> prop1:"Properties unlikely, but allowed" >> }.{ >> //class properties >> staticMethod(){} >> }; >> >> 1. If a "constructor" method is supplied as part of the object >> literal, it will be used as the new constructor, and take the LHS >> constructor as its prototype. If not, an new empty constructor will be >> created instead and take the LHS constructor as its prototype. >> 2. The rest of the object literal will be used as the new constructors >> prototype, and it will use the LHS's prototype as it's prototype. >> 3. The result of the <| operand in my example would be the new >> class/constructor function, so it can be assigned to "const ClassName" >> or as in my example, the .{ operator can be used to add class methods >> and still return the correct result. > > > That would indeed work: If the lhs is a function and the rhs a non-function > object, then the rhs is basically used as the prototype (including a nested > constructor inside) of the “sub-class”. > > However: What are the advantages over class literals? You would still need to > introduce a new mechanism (the overloading of <|). My favorite solution for > avoiding the introduction of a new mechanism is still Allen’s <| for two > function plus Function.prototype.* methods that add class methods and > prototype methods. But I like (minimal) class literals even more than that: > > class ClassName extends SuperClass { > constructor(/*constructor parameters */) { > //constructor body > super.constructor(/*arguments to super constructor */); > this.{ > //per instance property definitions > } > } > method1(){ return super.method1(); } > method2(){} > prop1:"Properties unlikely, but allowed" > class: > //class properties > staticMethod(){} > }; > > Isn’t that the same *in spirit* as your proposal, but nicer to read? In both > cases you introduce something new: Either a new overloading or minimal > syntactic sugar. > > -- > Dr. Axel Rauschmayer > > a...@rauschma.de > twitter.com/rauschma > > home: rauschma.de > blog: 2ality.com > > > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss