> Am 10.12.2016 um 20:48 schrieb stepharong <[email protected]>: > > > 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? 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 >
