Dale

I missed your remark about traits.�

I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one.�

Now ideally I would like to have�

(I hate so much this google nonUI)

- state with traits with a nice initialization process.

- Now Pablo did a nice and simple implementation of Talents (dynamic traits). I should have a look because if we could unify it and have�

either a trait statically applied to a class (what we have now) and a trait being applicable to an instance then it would be really good.�

Now making the tools traits-aware is much more than just having traits in the language.�

� � - change

� � - loading

� � - editing

� � - overloading when we compile a method that comes from a trait we should be able to say that it overrides.....

What we did with the "unification" of traits and classes and the use of traits inside the kernel is a mistake (in Squeak andreas if I recall made Trait a subclass of classDescription

and this is not good either - even if he marketed it as a good idea) and we will iterated to remove the use of traits from Class and friends.�

Then ideally I would like to iterate over the�

� � �- reflective API (because we should be able to simply access the "class" �of a compiledMethod from where the traits is coming from or where it is installed�

� � �- revisite the implementation because the clause composition.

I think that the tools should not manipulate traits as classes because traits are not classes.�

Then doing this we will clarify that the traits and classes must not be polymorphic because they are not.�