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

Dmitry A. Soshnikov dmitry.soshnikov at gmail.com
Mon May 16 04:54:27 PDT 2011


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.

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.

So again, better to have something like this:

class Bar extends Foo {
     includes Comparable
}

where Comparable is a trait/mixin. It becomes an ancestor of the 
instance (via some hidden-class), E.g.:

let bar = Bar.new(...args)

Then we have the following hierarchy:

bar -> HiddenClass -> Foo
            |
            |
        Comparable

I.e. beside the vertical ("tower") inheritance at each link of a chain 
we also have horizontal inheritance via mixins. Thus HiddenClass before 
going to its prototype chain, first try to find the property in the 
horizontal chain, i.e. in Comparable.

A simple object may also mix some functionality without using a class 
(if a user still needs pure prototype-based code reuse):

let bar = Object.mixing(Object.create(foo), Comparable);

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 :)).

So we may actually understand what's going on by looking at the grammar, 
but nevertheless, if it's not hard, some simple examples would be nice.

Besides, I restore my previous syntactic proposal (Coffee/Ruby-like 
again) with a simple rule: (1) `this` evaluated in the class body is the 
class, (2) `this` evaluated in the instance method body is the instance. 
These two rules seems quite simple, not-overheaded, and the class 
definition looks like as an object initialiser. I used @ as a sugar, 
though it's not essential currently. Also, notice, I used `initialize` 
for `new` or `constructor`, since it seems more exactly describes the 
essence of the method: 
http://dmitrysoshnikov.com/scheme-on-coffee/class.html

Dmitry.

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


More information about the es-discuss mailing list