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 <[email protected]> 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
>
> [email protected]
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
