> Am 11.12.2016 um 09:05 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? > 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.
Sounds good. I agree the old implementation was too heavy. The anonymous class case is surely the next obvious things. I played a bit with that approach. So I'm interested to have a real inplementation for that. Norbert > > 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/
