Hi,
my implementation is in https://github.com/tesonep/pharo-talents . It
does not have enough documentation, although the tests have working
examples. I have as an objective of this week write more documentation.
Any comment will be gratefully received.
thanks,
Pablo
On Sun, Dec 11, 2016 at 9:05 AM, stepharong <[email protected]> wrote:
>
>
> 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/
>
--
Pablo Tesone.
[email protected]
