2009/10/26 Alexandre Bergel <alexandre@bergel.eu>:
I recognized the issue we had with 'self explicitRequirement'. Methods acquired by a trait override methods defined in superclasses. This is the behavior everyone expect. However, when a method is used for a purpose different than defining functional behavior, then unwanted effect emerge.
Right.
For traits, requirements were programmatically inferred instead of using #explicitRequirement.
Not sure i understood. Is there a way to tell to not override the method automatically, if it provided in base class?
Hope it helps, Alexandre
On 26 Oct 2009, at 13:41, Igor Stasenko wrote:
2009/10/26 Alexandre Bergel <alexandre@bergel.eu>:
Hi Igor,
Trait named: #TraitGroup uses: TraitA + TraitB + .... TraitN category: 'foo'
and suppose i want to use TraitGroup in one of my classes, but excluding one of the traits in the list above.. i.e. something like:
Object subclass: #Myclass uses: TraitGroup - TraitA ..
but the above code don't seem to work.. Any clues, how i can do that?
The exclusion is specified between a trait and a set of selectors, not between two traits.
You need to write for example:
Object subclass: #Myclass uses: TraitGroup - {#m1 . #m2}
If #m1 and #m2 are two methods of TraitA (i.e., defined on or acquired by TraitA).
Yes, i know Alex.
And this is awkward , because i can't control composition _indirectly_ , only directly.
The problem i want to solve is following:
A base trait (BaseTrait) provides a protocol , which implies accessing/using some state. This means, that trait having all methods which potential class would have, including accessors. But accessors is implemented as: 'self shouldBeImplemented'. In this way, i creating an error-proof and self-documenting trait , because developer could clearly see what methods should be overridden in a class which using the trait. Now for this trait, i creating a basic class, which implemets necessary methods by overriding some trait methods.
Object subclass: #MyBase uses: BaseTrait
now if i make a subclass of it,
MyBase subclass: #NextClass
i know, that its already implementing a protocol of BaseTrait.
However, i want to add more things to it, because i having a:
Trait named: #CompositeTrait uses: BaseTrait + TraitA + TraitB + ...
Next, i want to reuse the MyBase behavior by inheritance, and CompositeTrait by using it:
Mystate subclass: #NextClass uses: CompositeTrait
But here the problem: if i apply CompositeTrait, it will override all of the BaseTrait methods again, leaving no way how i can reuse the MyBase class methods, unless i'm explicitly specify all protocol of BaseTrait for exclusion.. Which is really awkward. Just compare this:
Mystate subclass: #NextClass uses: CompositeTrait - {#foo. #bar. #baz. ....... a list could be very long }
and this:
Mystate subclass: #NextClass uses: CompositeTrait - BaseTrait
moreover, whenever i change the BaseTrait protocol, i would need to revisit the NextClass declaration again and again, instead of doing nothing :(
Of course, you could say that solution is to not include the BaseTrait in CompositeTrait at first place. But i indend to do so, because in this way i'm clearly stating what interfaces the class should support, otherwise the only way how i would tell developer to not forget to include BaseTrait is write in CompositeTrat comment: 'Hey, pal, if you want to use thit trait, make sure that your class implements the BaseTrait protocol'. :)
Of course, these problems would go away if we could afford stateful traits(aka mixins).. Then really, there would be no need to use a class inheritance, and all classes could be composed from traits having an Object class as base class. But until then, i need to use some tricks , to deal with state.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel  http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.