2009/10/26 Alexandre Bergel <[email protected]>: > 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 <[email protected]>: >>> 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 >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
