If the <| operator's intent is to create new classes easily via composition, it
seems like its grammar should be
'class' friendly eg the LHS <| RHS could be a class and/or class expression as
in the following:
class Person {
constructor(name) {
private name;
@name = name;
}
describe() {
return "Person called "+@name;
}
}
class Worker = Person <| class {
constructor(name, title) {
private title;
super(name);
@title = title;
}
describe() {
return super.describe()+" ("+@title+")";
}
};
However the grammar as described would exclude the above.
Would the Set Literal Prototype grammar eventually be reconciled with the class
grammar
or do you feel it's a replacement? I ask because I suspect an application
programmer would not understand why the RHS could
take an ObjectLiteral (for example) but not an anonymous class - after all both
contain 'class' elements.
If the answer is 'no', it seems like '<|' fragments the ways to define a class
shape where
LHS <| {
constructor: function(name,title) {
Person.call(this,name);
this.title = title;
}
}
works but
LHS <| class {
constructor(name,title) {
private title;
super(name);
@title = title;
}
does not.
________________________________
From: Allen Wirfs-Brock <al...@wirfs-brock.com>
To: Russell Leggett <russell.legg...@gmail.com>
Cc: Axel Rauschmayer <a...@rauschma.de>; es-discuss <es-discuss@mozilla.org>
Sent: Sunday, October 2, 2011 3:19 PM
Subject: Re: Minor extension to Set Literal Prototype operator as minimal
classes
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
>I can see the "recursive stache" useful in some situations (although
>it is another syntax addition to object literals). It would allow for
>the ability to apply a deeply nested "patch" to an object, which is
>sort of interesting to think about. However, what I think this
>pattern, the original pattern, and Axel's pattern all lack is that it
>places too much emphasis on class members, and not enough on the
>prototype. Perhaps I'm being too nit-picky now, but I find that
>class/static members are a whole lot more rare than prototype/instance
>members. My proposal was shooting for a sweet spot where the 90% (a
>made up number of course) case of a constructor and some prototype
>methods could be handled in one object literal, effectively the same
>code as the body of a potential class literal.
>
The problem with:
>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(){}
>};
>
>
Is that the
SuperClass <| {
>...
>}part evaluates to the prototype object, not the constructor function and
>hence what you would be naming is the prototype. This, in general, is how
>stache has to work for arbitrary object literals where all you really are
>trying to do is set the [[Prototype]]. There really isn't anything special in
>your pattern that distinguishes it from that simple object case.
As has been discussed on this list before, if you are actually using prototypal
inheritance to construct your object abstractions then it really is the
prototype you want to name rather than the constructor function. EG:
const Person = Mammal <| {
> name: 'John Doe',
> constructor(sex,name) {
> super.constructor(sex);
> this.{name}
> }
>}
>
>
>console.log(typeof Person); //'object', not 'function'
>console.log(Person.name); //'John Doe'
Person is the prototypal person. You would then really like to create new
Person instances like:
let joe = new Person('male','Joe Smith'); // means roughly joe =
Object.create(Person).constructor('male','Joe Smith')
console.log(joe.name); //'Joe Smith'
>console.log(Object.getPrototypeOf(joe).name); //'John Doe'
However, new currently throws when applied to non-function objects. This is
something I would like to fix for ES.next.
Also, there is also an issue that in a definition like mine above the
constructor function that is being created really should automatically get a
'prototype' property that back references the object with the 'constructor'
property.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
