An "extend" operator is a natural companion to <|

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 18 14:55:01 PDT 2011


On Jul 18, 2011, at 11:26 AM, Dmitry A. Soshnikov wrote:

> On 18.07.2011 21:32, Allen Wirfs-Brock wrote:
>> 
>> I've recently been experimenting with coding both prototypal and class based object definitions using the various syntactic forms that are currently on the table.  Something has emerged from that which has surprised me.  I have never been a big fan of the "extend" method that is provided by a number of JavaScript frameworks. However, based upon my experiments I'm now think that something like extend solves several issues with the declarative object and class declarations that we have recently been discussing.
>> 
>> Just in case there is anyone on this list who isn't familiar with extend, here is a quick explanation. In most frameworks that support it, "extend" is invoked something like this: 
>>    obj.extend(extensionObj)
>> It copies the own properties of  extensionObj and makes corresponding own properties for obj.
> 
> JFTR: object.extend(...) first appeared in Prototype.js and was borrowed there from Ruby. In Ruby though, this method method is delegation-based (that is, a hidden class is created which is inserted as a direct ancestor of the object and the superclass of the hidden class is set to extending module). That is, if something changes in the mixed module, the changes are reflected on the object which extended it.
> 

...

> Perhaps ES wants also this approach. OTOH, "extend" practice is already strongly used in JS and from this viewpoint it makes sense to make extending with copying and not using delegation.

That would require at mutable [[Prototype]] which is something we have been trying to stay away from in TC39.

> 
> 
...
> Am I alone here who want to put a space after the methods in this proposal? ;) It's like operators, really:

feel free to use one.  a space isn't syntactically significant in that position. 

...
> 
> 
>>           if (!this.__validate(x,y)) throw "invalid";
>>           return this <| {
>>                   __x: x,
>>                   __y: y
>>                  }
>>       };
>> }
>> 
> 
> What's the reason we want back to desugared factories (with all this explicit stuff, manual `return`, setting manually proto, etc) instead of improving constructors syntax by forming them to classes? Is the syntax already accepted for classes by the way? I remind again this syntactic form which seems (for me?) more elegant http://dmitrysoshnikov.com/scheme-on-coffee/class.html.

One of the design issues in the class proposals has been how to distinguish between prototype properties and per instance properties added by a constructor.  The current class proposal uses public/private declarations in the constructor for that purpose. This proposal of mine is suggesting that instead of adding special syntax just for constructors in class declarations we should consider adding a new operator (<&) with multiple uses that can also address the constructor use case.



...

> I'm really sorry, perhaps it's only for me, but all these examples seem to me too cryptic in respect of syntax (even like Perl). All these `} <& {` seem for me as a syntactic noise. I even better would like to see some longer but humanized "extends" keyword. Maybe it's about the habit and perhaps later it will become for me not so cryptic (after all I can accept -> #, {||}, etc. as an alternative for `function`).
> 

I'm sympathetic  to the crypticness argument but I get just as many arguments on the other side of the issue when proposing keyword based extensions.    Also, it is generally harder (but not necessarily impossible) to add keyword operators then it is special character based operators.  Automatic semi-colon insertion gets in the way.
Consider:

var function extend() {};
var bar = foo
   extend ({y:20});

> E.g.
> 
> let foo = {x: 10}
> 
> // delegation-based extending
> let bar = foo extend {
>   y: 20;
> };
> 
> // copy-based extending
> bar.mixin({
>   z: 30
> });
> 
> Pity btw, that < is already borrowed and is a normal operator, we could use it instead of <| which is not the best on different fonts. <bikesheding value="Mayber a back arrow? <- " />

 foo <-bar  //   foo < (-bar)

Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110718/56e765df/attachment.html>


More information about the es-discuss mailing list