>>> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
