[Pharo-project] Trait conflicts wtf?

Mariano Martinez Peck marianopeck at gmail.com
Mon Aug 20 18:39:02 CEST 2012


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 <
marianopeck at gmail.com> wrote:

>
>
> On Mon, Aug 20, 2012 at 4:46 PM, Guillermo Polito <
> guillermopolito at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120820/09b3900d/attachment.html>


More information about the Pharo-project mailing list