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
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
