On Oct 3, 2011, at 3:11 AM, Axel Rauschmayer <a...@rauschma.de> wrote:
> 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. Actually no - see below... > 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. > The grammar rules for ProtoLiteral cover the various literal types including regex, so they're fairly broad now. I wasn't suggesting any expression, just integration of the class grammar since the intent of the '<|' operator seems to be to make it easier to extend classes. Having the '<|' operator exclude class constructs seems counterintuitive unless it is an alternative syntax to the classes proposal. > > 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