Ah, OK. So you are suggesting
Person <| class Worker { … }
instead of
class Worker extends Person { … }
Both solutions can be justified: The first solution makes <| more universal.
The second solution limits <| to "under the hood" work and lets class literals
be a higher level of abstraction.
An additional reason might be that the current grammar keeps <| and class
literals independent. I think the former is currently more likely to make it
into ES.next than the latter.
On Oct 3, 2011, at 12:46 , Kam Kasravi wrote:
>
>
> On Oct 3, 2011, at 3:11 AM, Axel Rauschmayer <[email protected]> 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 <[email protected]>
>>> To: Russell Leggett <[email protected]>
>>> Cc: Axel Rauschmayer <[email protected]>; es-discuss <[email protected]>
>>> 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
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> --
>> Dr. Axel Rauschmayer
>> [email protected]
>> twitter.com/rauschma
>>
>> Home: rauschma.de
>> Blog: 2ality.com
>>
--
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
