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.
For traits, requirements were programmatically inferred instead of using #explicitRequirement. 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
