I noted some open issues on "Classes with Trait Composition"

[Dmitry A. Soshnikov]

On 16.05.2011 19:02, Brendan Eich wrote:
> On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
>
>> On 16.05.2011 10:49, Brendan Eich wrote:
>>> On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
>>>
>>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues 
>>>>
>>>>
>>>> This looks pretty good at a glance, but it's a /lot/, and it's new.
>>>
>>> Looking closer, I have to say something non-nit-picky that looks bad 
>>> and smells like committee:
>>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#inheritance
>>>
>>> Two kinds of inheritance, depending on the dynamic type of the 
>>> result of evaluating the //MemberExpression// on the right of 
>>> ''extends''? That will be confusing.
>>>
>>> Is the traits-composition way really needed in this proposal? If so, 
>>> then please consider not abuse ''extends'' to mean ''compose'' 
>>> depending on dynamic type of result of expression to its right.
>>>
>>
>> Some simple examples of all use-cases would are needed I think.
>>
>> Regarding `new` keyword for the constructor (aka initializer), after 
>> all, it als may be OK. E.g. Ruby uses `new` as exactly the method of 
>> a class -- Array.new, Object.new, etc. Though,  `constructor` is also 
>> good yeah.
>
> My point is not to bikeshed, rather (a) to name existing prototype 
> properties minimally, (b) to avoid preempting other names.
>
> Good, bad, or in between, the prototypal pattern in JS for constructor 
> C binds C.prototype.constructorr to C. It does not bind C.prototype.new.
>

Yeah, agreed.

>
>> Regarding two inheritance types, I think better to make nevertheless 
>> one inheritance type -- linear (by prototype chain). And to make 
>> additionally small reusable code units -- mixins or traits -- no 
>> matter. Thus, of course if they will also be delegation-based and not 
>> just copy-own-properties, then we automatically get a sort of 
>> multiple inheritance.
>
> Self has multiple prototypes and you can use them for all kinds of 
> inheritance patterns.
>
> Parents are Shared Parts... 
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.1447&rep=rep1&type=pdf>
>
> Organizing programs without classes 
> <http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=77703261C2A470793139A1F79D8467AC?doi=10.1.1.127.5320&rep=rep1&type=pdf>
>
>

Yes, I've heard about Self'ish multi-protos but don't know the lang, 
though have heard that JS has taken some things from it. Thanks for the 
paper.

>> Delegation-based mixins though can be implemented as a library using 
>> proxies (example: 
>> https://github.com/DmitrySoshnikov/es-laboratory/blob/master/examples/mixin.js, 
>> implementation: 
>> https://github.com/DmitrySoshnikov/es-laboratory/blob/master/src/mixin.js, 
>> notice I also used Object.new :)).
>
> Proxies are too costly, though. They always have a handler full of traps.

Yep, it was just an example.

> The idea with classes is to capture prototypal inheritance as used today.

Yeah, classes are just a sugar in this case, the same as in Coffee, the 
same as in Python.

> The idea with traits is to make composition flexible, with fast 
> failure on conflict and tools to rename around conflicts.
>
Yes, but IMO the most interesting for programmers the ability to mix 
reusable code. The conflict-resolver is derived. And if to implement 
this conflict-resolve traits will have to be just things for static 
augmentation of objects with own properties, I think I choose better 
just mixins.

Dmitry.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110516/7ca4a0f3/attachment-0001.html>