> 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
