I noted some open issues on "Classes with Trait Composition"
Dmitry A. Soshnikov
dmitry.soshnikov at gmail.com
Mon May 16 12:32:51 PDT 2011
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>
More information about the es-discuss
mailing list