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.��

Where is this Talents implementation?��

I should ask pablo.

It is better than the one of jorge because it is not based on reflectivity but anonymous class.��

We will document it.��

Stef

thanks,

Norbert

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.��

Stef

--

Using Opera's mail client: http://www.opera.com/mail/