October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] (a = b) => (a hash = b hash)

by Andrew P. Black

RIght on both counts. sameElements: is in RoelTyper On 26 Oct 2009, at 07:56, Nicolas Cellier wrote: > This is exactly SequenceableCollection>>#hasEqualElements: > I have no #sameElements: in core. > > Nicolas hasSameSequenceOfElements: is still a better name than hasEqualElements: :-)

Oct. 26, 2009

Re: [Pharo-project] Feature request: All uses of Trait

by StÃ©phane Ducasse

add an issue in the bug tracker Stef On Oct 26, 2009, at 5:04 PM, Igor Stasenko wrote: > 2009/10/26 Alexandre Bergel <alexandre(a)bergel.eu>: >> Just send #users to a trait. >> > ... and integrate it with browers :) > > >> Cheers, >> Alexandre >> >> >> On 25 Oct 2009, at 02:26, Igor Stasenko wrote: >> >>> It would be cool to have a 'references-to' support for traits. >>> Or maybe its there already? >>> >>> How can i quickly look, what classes using the trait? >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2009

Re: [Pharo-project] Traits composition question

by StÃ©phane Ducasse

this is an implementation bug we should once fix. > 2009/10/26 Alexandre Bergel <alexandre(a)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(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2009

Re: [Pharo-project] question about results of MessageTally

by StÃ©phane Ducasse

please resurrect that and do simple increment :) Now we can use Momo tree widget for ast and this is cool stef On Oct 26, 2009, at 12:26 AM, Henrik Sperre Johansen wrote: > Personally, I always change to 0.1 in spyOn: (my experience in VW > was that doing 0.0 makes the tree building take a long time). > You'd probably also want to try out > TimeProfileBrowser onBlock: > instead of MessageTally spyOn:, > while not a huge improvement, it's nice to have the method source > accessible directly. > I had a dream of making a new one, with a proper treeview of the > tally (and a button for auto-expand to certain %, no need to worry > if you'd set the cutoff correctly before starting the tally), color- > coding of the hotspots in the method view, and store/compare of > tallies, but never seem to get around to it. > Well, I did start once, but my head started hurting too soon from > the total lack of separation between result production/storage/ > presentation responsibilities in MT. > > Cheers, > Henry > > > On 25.10.2009 21:00, Laval Jannik wrote: >> yes, with 0 it works. >> >> But, in some cases, we would like to have all branches. >> So, I will do the method spyOn:cutoff:, and keep the 1% threshold for >> spyOn:. >> >> Cheers, >> Jannik >> >> >> On Oct 25, 2009, at 20:54 , Adrian Lienhard wrote: >> >> >> >>> Have you tried with 0? I guess you get way too much in the tree >>> (especially when you trace a larger part of your application and not >>> only adding elements to a dictionary). It seems that 1% is a >>> sensible >>> default as usually it does not make sense to look into these >>> branches >>> more closely as you cannot optimize them much. >>> >>> Adrian >>> >>> On Oct 25, 2009, at 19:42 , Laval Jannik wrote: >>> >>> >>> >>>> Hi Adrian, >>>> >>>> Now I understand the "problem". >>>> So we can use "report:cutoff:" which allows us to give a specific >>>> value for the threshold. >>>> >>>> I will create a new method, spyOn:cutoff:. >>>> >>>> I think the method "spyOn:" must have the threshold equals to 0. >>>> No ? >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> On Oct 24, 2009, at 12:08 , Adrian Lienhard wrote: >>>> >>>> >>>> >>>>> Hi Jannik, >>>>> >>>>> Interesting question! >>>>> >>>>> You left out an important part oft the tally: the part about GC >>>>> activity. >>>>> >>>>> For the large dictionary I get: >>>>> >>>>> **GCs** >>>>> full 9 totalling 1,696ms (1.0% uptime), avg 188.0ms >>>>> incr 3776 totalling 186,310ms (94.0% uptime), avg 49.0ms >>>>> >>>>> That is, 95% of time is spent in GC! A lot of incremental GC >>>>> cycles >>>>> are triggered because for each at:put: a new association >>>>> instance is >>>>> created. The larger the dictionary, the larger is the new memory >>>>> space >>>>> and hence the incremental GC takes longer to complete. In the >>>>> above >>>>> tally the average was 49ms compared to >>>>> >>>>> incr 275 totalling 1,113ms (58.0% uptime), avg 4.0ms >>>>> >>>>> for the smaller dictionary. Therefore, the ratio between actual >>>>> method >>>>> execution time and GC time differs significantly between the two >>>>> runs. >>>>> As a result, a lot of branches of the tally are below a total of >>>>> 1% >>>>> runtime in the second case. Message tally has a threshold that >>>>> cuts >>>>> off branches with less than 1% runtime. Therefore you see less >>>>> details. >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> >>>>> On Oct 24, 2009, at 07:21 , Laval Jannik wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> when I use MassageTally>>spyOn: on the creation of a Dictionary, >>>>>> results have not the same details according to the size of >>>>>> Dictionary. >>>>>> >>>>>> For example: >>>>>> === >>>>>> |n| >>>>>> MessageTally spyOn:[ >>>>>> n := Dictionary new. >>>>>> 1 to: 400000 do:[:each | n at: each put:each]. >>>>>> ] >>>>>> === >>>>>> >>>>>> returns this results: >>>>>> >>>>>> ==== >>>>>> - 1745 tallies, 1751 msec. >>>>>> >>>>>> **Tree** >>>>>> -------------------------------- >>>>>> Process: (40s) 1964: nil >>>>>> -------------------------------- >>>>>> 45.8% {802ms} Dictionary(Set)>>atNewIndex:put: >>>>>> |43.6% {763ms} Dictionary(Set)>>fullCheck >>>>>> | |39.4% {690ms} Dictionary(Set)>>grow >>>>>> | | |27.2% {476ms} Dictionary>>noCheckAdd: >>>>>> | | | |25.2% {441ms} Dictionary(Set)>>findElementOrNil: >>>>>> | | | | |23.6% {413ms} Dictionary>>scanFor: >>>>>> | | | | |1.6% {28ms} primitives >>>>>> | | | |2.0% {35ms} primitives >>>>>> | | |9.2% {161ms} primitives >>>>>> | | |3.0% {53ms} Array(SequenceableCollection)>>do: >>>>>> | |2.4% {42ms} primitives >>>>>> | |1.8% {32ms} SmallInteger(Magnitude)>>max: >>>>>> |2.2% {39ms} primitives >>>>>> 22.4% {392ms} Association class>>key:value: >>>>>> |18.9% {331ms} Association class(LookupKey class)>>key: >>>>>> | |16.3% {285ms} Association(LookupKey)>>key: >>>>>> | |2.6% {46ms} primitives >>>>>> |1.9% {33ms} Association>>value: >>>>>> |1.6% {28ms} primitives >>>>>> 4.4% {77ms} Dictionary(Set)>>findElementOrNil: >>>>>> |2.3% {40ms} primitives >>>>>> |2.1% {37ms} Dictionary>>scanFor: >>>>>> 1.9% {33ms} primitives >>>>>> ==== >>>>>> >>>>>> But, if I do: >>>>>> === >>>>>> |n| >>>>>> MessageTally spyOn:[ >>>>>> n := Dictionary new. >>>>>> 1 to: 4000000 do:[:each | n at: each put:each]. >>>>>> ] >>>>>> === >>>>>> >>>>>> results are: >>>>>> ==== >>>>>> - 179772 tallies, 180312 msec. >>>>>> >>>>>> **Tree** >>>>>> -------------------------------- >>>>>> Process: (40s) 1964: nil >>>>>> -------------------------------- >>>>>> 3.1% {5590ms} Dictionary(Set)>>atNewIndex:put: >>>>>> |2.8% {5049ms} Dictionary(Set)>>fullCheck >>>>>> | 2.3% {4147ms} Dictionary(Set)>>grow >>>>>> | 1.3% {2344ms} Dictionary>>noCheckAdd: >>>>>> 1.0% {1803ms} Association class>>key:value: >>>>>> ==== >>>>>> >>>>>> Where are the rest of the process ? >>>>>> Does anybody understand this behavior ? can you explain ? >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Jannik >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>>> >>>> --- >>>> Jannik Laval >>>> PhD Student - Rmod Team - INRIA >>>> Certified Project Management Associate (IPMA) >>>> >>>> http://www.jannik-laval.eu >>>> http://rmod.lille.inria.fr >>>> >>>> --- >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >> --- >> Jannik Laval >> PhD Student - Rmod Team - INRIA >> Certified Project Management Associate (IPMA) >> >> http://www.jannik-laval.eu >> http://rmod.lille.inria.fr >> >> --- >> >> >> _______________________________________________ >> Pharo-project mailing list >> >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2009

Re: [Pharo-project] Traits composition question

by Igor Stasenko

2009/10/26 Alexandre Bergel <alexandre(a)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(a)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(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

Re: [Pharo-project] Traits composition question

by Alexandre Bergel

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 <alexandre(a)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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 26, 2009

Re: [Pharo-project] Traits composition question

by Igor Stasenko

2009/10/26 Alexandre Bergel <alexandre(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

Re: [Pharo-project] Feature request: All uses of Trait

by Igor Stasenko

2009/10/26 Alexandre Bergel <alexandre(a)bergel.eu>: > Just send #users to a trait. > ... and integrate it with browers :) > Cheers, > Alexandre > > > On 25 Oct 2009, at 02:26, Igor Stasenko wrote: > >> It would be cool to have a 'references-to' support for traits. >> Or maybe its there already? >> >> How can i quickly look, what classes using the trait? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 26, 2009

Re: [Pharo-project] Feature request: All uses of Trait

by Alexandre Bergel

Just send #users to a trait. Cheers, Alexandre On 25 Oct 2009, at 02:26, Igor Stasenko wrote: > It would be cool to have a 'references-to' support for traits. > Or maybe its there already? > > How can i quickly look, what classes using the trait? > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 26, 2009

Re: [Pharo-project] issue 496: Morph>>heading

by Mariano Martinez Peck

2009/10/26 Marcus Denker <denker(a)acm.org> > > >> However, it would be a good idea to put all the interesting eToy stuff in >> an external package so that those who want to load that stuff, are able to >> do it. >> >> >> >> > >> Because, make an external package of it needs a big work... >> > > I don't think so. > > > Etoy is more complex than you think. It would be (nearly) impossible. > > Grrr Sorry, so, I may be a dreamer :( Of course I know very little about Morphic, so I totally believe you. > > You just need to create the package. And then, instead of removing code, > you move it to that package. What can be a lot of work is to keep that > package up to date and working, but that's not Pharo responsibility. > > > Nope. Etoy is programed in a way that makes things like this *a lot* of > work. > > I was just asking as one of the Pharo goals is to be "clean". Is even that complicated to do it in little steps? For example, consider this particular case Jannik said as a step. Again, I know nothing about Morphic :( > > Marcus > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2009