Keep in mind that class literals are syntactic sugar and that Russells
suggestion was about using his modified <| operator as a replacement for class
literals.
What you are suggesting is a generic <| operator, where both LHS and RHS can be
arbitrary expressions. However, the point of <| is that the RHS must be a
literal (function declaration or object literal), because it actually should be
considered to be a part of that literal. It creates the RHS with the
appropriate prototype. Allowing any expression as the RHS would mean that the
prototype of the RHS would have to be changed and that is much more tricky.
On Oct 3, 2011, at 11:35 , Kam Kasravi wrote:
> 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
>
>
--
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
