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