trait composition conflict autoresolution

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

trait composition conflict autoresolution

aizcorbe
Hi all, I'm doing some work with traits, and I found something like this case:

Trait T1>>m1
     ^self requirement

Trait T2>>m1
    doSomeStuff

Class C1 uses: T1 + T2
[note, i'm not excluding m1 from T1 in the T1 + T2 composition.]
And the resulting:
C1>>m1
    doSomeStuff

It is just ok, since the other m1 is just a mark for a requiredMethod, but I find this a little weird, since do not follow the Trait definition. (at least the one I read, maybe it changed!).  Wouldn't be better to automatically add the exclusion at the composition?
Class C1 uses: T1 - {#m1} + T2

In this way the definition would be followed without any exception (and it will be explicit with what is going on).  This is just a suggestion, anyway it works great!

btw... why there are two requirement marks?:
Object>>requirement
        self error: 'Implicitly required method'

Object>>explicitRequirement
        self error: 'Explicitly required method'

the question is, if I use #requirement, I'm explicitly requiring that method.  Is there any situation where I should use #requirement?

Cheers
Reply | Threaded
Open this post in threaded view
|

Re: trait composition conflict autoresolution

Stéphane Ducasse
> Hi all, I'm doing some work with traits, and I found something like this
> case:
>
> Trait T1>>m1
>     ^self requirement
>
> Trait T2>>m1
>    doSomeStuff
>
> Class C1 uses: T1 + T2
> [note, i'm not excluding m1 from T1 in the T1 + T2 composition.]
> And the resulting:
> C1>>m1
>    doSomeStuff
>
> It is just ok, since the other m1 is just a mark for a requiredMethod, but I
> find this a little weird, since do not follow the Trait definition. (at
> least the one I read, maybe it changed!).  Wouldn't be better to
> automatically add the exclusion at the composition?
> Class C1 uses: T1 - {#m1} + T2

not really. Or this means that the composition algo does not work well.
Now since C1 redefined m1 in both cases you will have C>>m1 taking precedence over T1>>m1.
I already forget but I discussed with tom and in javascript it proposed a different one
than the ones we have in smalltalk and it was coherent too.


Now there is a bug in pharo and squeak3.9 because if C1 is in fact the superclass
of the class using the trait then the requirement is not considered as fullfiled or something like that.]

>
> In this way the definition would be followed without any exception (and it
> will be explicit with what is going on).  This is just a suggestion, anyway
> it works great!
>
> btw... why there are two requirement marks?:
> Object>>requirement
> self error: 'Implicitly required method'
>
> Object>>explicitRequirement
> self error: 'Explicitly required method'
>
> the question is, if I use #requirement, I'm explicitly requiring that
> method.  Is there any situation where I should use #requirement?

I do not remember.

>
> Cheers
>
> --
> View this message in context: http://forum.world.st/trait-composition-conflict-autoresolution-tp2235790p2235790.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: trait composition conflict autoresolution

aizcorbe
Stéphane Ducasse wrote
>> Hi all, I'm doing some work with traits, and I found something like this
>> case:
>>
>> Trait T1>>m1
>>     ^self requirement
>>
>> Trait T2>>m1
>>    doSomeStuff
>>
>> Class C1 uses: T1 + T2
>> [note, i'm not excluding m1 from T1 in the T1 + T2 composition.]
>> And the resulting:
>> C1>>m1
>>    doSomeStuff
>>
>> It is just ok, since the other m1 is just a mark for a requiredMethod, but I
>> find this a little weird, since do not follow the Trait definition. (at
>> least the one I read, maybe it changed!).  Wouldn't be better to
>> automatically add the exclusion at the composition?
>> Class C1 uses: T1 - {#m1} + T2

>not really. Or this means that the composition algo does not work well.
>Now since C1 redefined m1 in both cases you will have C>>m1 taking precedence over T1>>m1.
>I already forget but I discussed with tom and in javascript it proposed a different one
>than the ones we have in smalltalk and it was coherent too.

Well, what I tried to say is that C1 do not redefine m1, it gets T2>>m1 from the T1 + T2 composition.  
So, is there a conflict if I compose T1 + T2 and do not redefine m1 in the composition client?
Or is this "improvement"  OK? (explicit required methods do not produce composition conflicts),
since having a conflict between a real message implementation and a explicitRequirement marked message doesn´t make any sense


>Now there is a bug in pharo and squeak3.9 because if C1 is in fact the superclass
>of the class using the trait then the requirement is not considered as fullfiled or something like that.]

Do you mean that should be expected that a trait's required method shouldn't hide a superclass implementation for that message?

All my doubts about this issue are actually one: does a trait's required method any special behavior with respect to the composition (conflicts with equals named messages in the composition, overrides equals named messages in the composition's client superclass, etc), or these messages behave exactly like any other message?
Reply | Threaded
Open this post in threaded view
|

Re: trait composition conflict autoresolution

Stéphane Ducasse
>>> Well, what I tried to say is that C1 do not redefine m1, it gets T2>>m1
>> from the T1 + T2 composition.  

Ah ok!
Then this is normal you have a requirement in T1 and it is fulfilled with T2.
This is correct!

>> So, is there a conflict if I compose T1 + T2 and do not redefine m1 in the
>> composition client?

no

>> Or is this "improvement"  OK? (explicit required methods do not produce
>> composition conflicts),

it make sense no?

>> since having a conflict between a real message implementation and a
>> explicitRequirement marked message doesn´t make any sense

??

>>>
>>> of the class using the trait then the requirement is not considered as
> fullfiled or something like that.]
>>
>> Do you mean that should be expected that a trait's required method
>> shouldn't hide a superclass implementation for that message?


There is a bug if the required methods is in the superclass
then


>>
>> All my doubts about this issue are actually one: does a trait's required
>> method any special behavior with respect to the composition (conflicts
>> with equals named messages in the composition, overrides equals named
>> messages in the composition's client superclass, etc), or these messages
>> behave exactly like any other message?

they don't. The composition treats them as special.
And we were thinking to remove them because they are too static and may be replace that with a class annotation.
if you are interested have a look at the discussion in this mailing-list a year ago.

Stef


>>
>>
> --
> View this message in context: http://forum.world.st/trait-composition-conflict-autoresolution-tp2235790p2236064.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project