Mariano
Mail communication is difficult and takes much more energy than face to face.
I do not have this energy now and answer a good answer, so we can talk at esug or via chat (voice) no text for me.
What I remember is that there is a problem in the trait implementation but I do not remember it. Damien C. should know it.
Stef
> We forgot to say that the motivation of this is that if we throw an error or take an assumption on how to resolve the conflict, plus some other changes we already done, we should be able to NOT use the Compiler at all when installing traits. The only place where we would still need the Compiler is when using Alias, but so far we have only ONE user in the image and it is TPureBehavior. Meaning that with this changes, in the 99.99% of the cases (it only uses Compiler when importing Traits with aliases) we can have kernels and boostraped images that can grow (even with traits) without the compiler.
> Anyway, besides this "benefit", we didn't like that it silently fails and creates a method saying "self traitConflict".
> Maybe we are not saying something....
>
> Cheers,
>
> On Mon, Aug 20, 2012 at 4:48 PM, Mariano Martinez Peck <
[hidden email]> wrote:
>
>
> On Mon, Aug 20, 2012 at 4:46 PM, Guillermo Polito <
[hidden email]> wrote:
> Trait named: #TA
> uses: {}
> category: 'ABC'
>
> Trait named: #TB
> uses: {}
> category: 'ABC'
>
>
> TA>>a
> ^10
>
> TB>>a
> ^10
>
> Object subclass: #A
> uses: TA + TB
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'ABC'
>
> ==>
>
> A>>a
> ^self traitConflict
>
>
> ?
>
> Why not an exception from a conflictive composition? This is to Mariano me a silent failure :/
>
>
> Or assume a resolution (like when selectors of classes have precedence over trait methods)
>
>
> Guille
>
>
>
> --
> Mariano
>
http://marianopeck.wordpress.com>
>
>
>
> --
> Mariano
>
http://marianopeck.wordpress.com>
Locked
