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:
>>>> 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:
>>> 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.
>> 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...
> Organizing programs without classes
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
>> Delegation-based mixins though can be implemented as a library using
>> proxies (example:
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss