June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object>>#if:then:else:

by Sven Van Caekenberghe

I never heard of that, it is cool, Esteban ! There are not many senders though. Thx, Sven On 18 Jun 2013, at 13:09, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I do not like it :) > > also, you already have #in: > which is more generic and allows simplifications: > > <my complex expression> in: [ :blah | > blah = myTest > ifTrue: [ blah some ] ] > ifFalse: [ blah other ] ] > > and also the advantage is that you are not restricted to #ifTrue:ifFalse: > > Esteban > > On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 18/06/2013 12:27, Camille Teruel a Ã©crit : >>> >>> On 18 juin 2013, at 11:20, Goubier Thierry wrote: >>> >>>> Hi Camille, >>>> >>>> It's not bad as things goes, because it does look a bit like >>>> non-smalltalk code (i.e. the if then else structure) except that the >>>> precise meaning is very much Smalltalk : >>> >>> Ok the name may be confusing. >>> So if you rename it to something like #if:do:elseDo:, it would be more >>> smalltalkish and there is no confusion with classical if-then-else. >> >> Maybe, that would help. >> >>>> if: has a receiver, and there is a not so intuitive relationship >>>> between the bloc parameters and the receiver. >>> >>> Talking to an arbitrary object is the goal, since booleans are not very >>> talkative kind of object. >>> Compare >>> >>> | temp | >>> temp := <complexExpression> >>> temp isNil ifTrue: [...] ifFalse: [... temp ...] >>> >>> with: >>> >>> <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] >>> >>> ifNil:ifNotNil: is not better only because it is shorter, it is better >>> because I am talking to the object I am auditing, not a stupid boolean >>> that knows nothing else but its truth value. >> >> Yes, but I know firsthand (because I used Smalltalk before that idiom was introduced) that it represent one more idiom to learn, and it's still not familiar. >> >> The same goes with withStreamDo: or what is that idiom again I sometimes encounter. >> >>>> Honestly, as far as code reviews goes, I'll prefer the temp >>>> refactoring. Understandable without having to search for the >>>> implementors of #if:then:else: >>> >>> I know this would break a long time tradition and people may not like >>> it, so that's a question of taste and style, not understandability. >>> There would be only one implementor, the implementation is really simple >>> and the selector is explicit. >> >>> Anyone can get use to it in less than 2 min. >> >> It's one more thing to get used to and to explain to beginners in say 10 minutes per idiom... (describe, give an example, let them practice, rinse and repeat for each idiom). >> >> Add all the new idioms and, instead of explaining Smalltalk in half a day, you spend a few days doing explaining all those idioms and not doing more interesting stuff. >> >> Soon, you end up like ocaml, where your minimum introduction time is a week, not half a day. >> >>> Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: >>> ,... every time? >> >>> No because people learned what they do when they learned Smalltalk, and >>> I'm sure it didn't get them more than a few minutes. >> >> Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your variant of if-else, and, and ... On some of those, I have to look for the implementors, and I'm really happy to benefit from the smart suggestions in the new browsers. (Additionally, code patterns using cull: in pharo more often than not are very poorly documented about the arguments that are given to the block). >> >> Smalltalk is disruptive enough as it is (and still is after all those years) to try not to make it more complex. I'd prefer efforts making obvious really complex patterns instead of idioms with a not so great cognitive load to effectiveness. >> >> I'd be happy to have a shorter list of methods and extensions on Object, as well :) >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Guillermo Polito

On Tue, Jun 18, 2013 at 1:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > well... afaik, no one outside pharo community is using the configurations, > the other guys on vm-dev prefer the old way of doing things. > > also, the group "pharo" is intended to include the things necessary to > produce a "pharo vm"... this is what time ago was in the > ConfigurationOfPharoVM. That means: you can produce a CogVM without loading > group "pharo", but not a Pharo VM. > so so... Because without the compatibility package the configuration does not even load in Pharo, and then you can build air only :). > > Esteban > > On Jun 18, 2013, at 10:26 AM, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Hi guys! > > I worked yesterday on making VMMaker load and work in Pharo2.0 with > filesystem. Now, I want to push my changes in a new development version of > ConfigurationOfCog. But I have some questions: > > Is ConfigurationOfCog used by other people besides Pharo? > > Because so far I see: > - there are two different groups in the conf: #common and #pharo. > - In #common, there is CMakeVMMaker (which in turn loads cairo from > files.pharo.org :)) and the oscog branch of VMMaker. Both have only as > latest committers Igor and Esteban :P. And I > - in #pharo there are nativeboost and some compatibility packages. > > So there are pharo specific stuff in both groups, or am I mistaken? Should > we keep both groups, or make them one and simplify? And how should I push > my changes related with filesystem (pharo-specific) then? > > Guille > > >

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Camille Teruel

On 18 juin 2013, at 13:09, Esteban Lorenzano wrote: > I do not like it :) I understand that (especially from a conservative who doesn't even like colors ;D ). > > also, you already have #in: > which is more generic and allows simplifications: > > <my complex expression> in: [ :blah | > blah = myTest > ifTrue: [ blah some ] ] > ifFalse: [ blah other ] ] > > and also the advantage is that you are not restricted to #ifTrue:ifFalse: Yes I love #in: , that was my inspiration. if:do:, if:do:elseDo: and while:do: would just be a bit of sugar to use sparingly just like in:. > > Esteban > > On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 18/06/2013 12:27, Camille Teruel a Ã©crit : >>> >>> On 18 juin 2013, at 11:20, Goubier Thierry wrote: >>> >>>> Hi Camille, >>>> >>>> It's not bad as things goes, because it does look a bit like >>>> non-smalltalk code (i.e. the if then else structure) except that the >>>> precise meaning is very much Smalltalk : >>> >>> Ok the name may be confusing. >>> So if you rename it to something like #if:do:elseDo:, it would be more >>> smalltalkish and there is no confusion with classical if-then-else. >> >> Maybe, that would help. >> >>>> if: has a receiver, and there is a not so intuitive relationship >>>> between the bloc parameters and the receiver. >>> >>> Talking to an arbitrary object is the goal, since booleans are not very >>> talkative kind of object. >>> Compare >>> >>> | temp | >>> temp := <complexExpression> >>> temp isNil ifTrue: [...] ifFalse: [... temp ...] >>> >>> with: >>> >>> <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] >>> >>> ifNil:ifNotNil: is not better only because it is shorter, it is better >>> because I am talking to the object I am auditing, not a stupid boolean >>> that knows nothing else but its truth value. >> >> Yes, but I know firsthand (because I used Smalltalk before that idiom was introduced) that it represent one more idiom to learn, and it's still not familiar. >> >> The same goes with withStreamDo: or what is that idiom again I sometimes encounter. >> >>>> Honestly, as far as code reviews goes, I'll prefer the temp >>>> refactoring. Understandable without having to search for the >>>> implementors of #if:then:else: >>> >>> I know this would break a long time tradition and people may not like >>> it, so that's a question of taste and style, not understandability. >>> There would be only one implementor, the implementation is really simple >>> and the selector is explicit. >> >>> Anyone can get use to it in less than 2 min. >> >> It's one more thing to get used to and to explain to beginners in say 10 minutes per idiom... (describe, give an example, let them practice, rinse and repeat for each idiom). >> >> Add all the new idioms and, instead of explaining Smalltalk in half a day, you spend a few days doing explaining all those idioms and not doing more interesting stuff. >> >> Soon, you end up like ocaml, where your minimum introduction time is a week, not half a day. >> >>> Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: >>> ,... every time? >> >>> No because people learned what they do when they learned Smalltalk, and >>> I'm sure it didn't get them more than a few minutes. >> >> Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your variant of if-else, and, and ... On some of those, I have to look for the implementors, and I'm really happy to benefit from the smart suggestions in the new browsers. (Additionally, code patterns using cull: in pharo more often than not are very poorly documented about the arguments that are given to the block). >> >> Smalltalk is disruptive enough as it is (and still is after all those years) to try not to make it more complex. I'd prefer efforts making obvious really complex patterns instead of idioms with a not so great cognitive load to effectiveness. >> >> I'd be happy to have a shorter list of methods and extensions on Object, as well :) >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >

June 18, 2013

Re: [Pharo-dev] There are still lots of Delay>>wait Processes

by StÃ©phane Ducasse

On Jun 18, 2013, at 11:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 June 2013 11:11, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Once igor finishes the TxModel and Athens it was planned to address the Delay problem. >> > > I don't think i am the only one who capable to fix it. :) I would love to be able to do it :) > Something broken in restoring Delay(s) after image restart (they > hanging for too far in the future). > That's my impression. > From other side, i do not see why Cookie should use [ Delay forEons wait] fork. > Instead, i would just replace implementation with code which checks > the time before giving answer > of cookie value. > So, if you won't use cookie value in heavy numerical-crunchy > calculations, this is completely fine. > >> Stef > > > > > -- > Best regards, > Igor Stasenko. >

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Esteban Lorenzano

I do not like it :) also, you already have #in: which is more generic and allows simplifications: <my complex expression> in: [ :blah | blah = myTest ifTrue: [ blah some ] ] ifFalse: [ blah other ] ] and also the advantage is that you are not restricted to #ifTrue:ifFalse: Esteban On Jun 18, 2013, at 1:05 PM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 18/06/2013 12:27, Camille Teruel a Ã©crit : >> >> On 18 juin 2013, at 11:20, Goubier Thierry wrote: >> >>> Hi Camille, >>> >>> It's not bad as things goes, because it does look a bit like >>> non-smalltalk code (i.e. the if then else structure) except that the >>> precise meaning is very much Smalltalk : >> >> Ok the name may be confusing. >> So if you rename it to something like #if:do:elseDo:, it would be more >> smalltalkish and there is no confusion with classical if-then-else. > > Maybe, that would help. > >>> if: has a receiver, and there is a not so intuitive relationship >>> between the bloc parameters and the receiver. >> >> Talking to an arbitrary object is the goal, since booleans are not very >> talkative kind of object. >> Compare >> >> | temp | >> temp := <complexExpression> >> temp isNil ifTrue: [...] ifFalse: [... temp ...] >> >> with: >> >> <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] >> >> ifNil:ifNotNil: is not better only because it is shorter, it is better >> because I am talking to the object I am auditing, not a stupid boolean >> that knows nothing else but its truth value. > > Yes, but I know firsthand (because I used Smalltalk before that idiom was introduced) that it represent one more idiom to learn, and it's still not familiar. > > The same goes with withStreamDo: or what is that idiom again I sometimes encounter. > >>> Honestly, as far as code reviews goes, I'll prefer the temp >>> refactoring. Understandable without having to search for the >>> implementors of #if:then:else: >> >> I know this would break a long time tradition and people may not like >> it, so that's a question of taste and style, not understandability. >> There would be only one implementor, the implementation is really simple >> and the selector is explicit. > >> Anyone can get use to it in less than 2 min. > > It's one more thing to get used to and to explain to beginners in say 10 minutes per idiom... (describe, give an example, let them practice, rinse and repeat for each idiom). > > Add all the new idioms and, instead of explaining Smalltalk in half a day, you spend a few days doing explaining all those idioms and not doing more interesting stuff. > > Soon, you end up like ocaml, where your minimum introduction time is a week, not half a day. > >> Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: >> ,... every time? > >> No because people learned what they do when they learned Smalltalk, and >> I'm sure it didn't get them more than a few minutes. > > Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your variant of if-else, and, and ... On some of those, I have to look for the implementors, and I'm really happy to benefit from the smart suggestions in the new browsers. (Additionally, code patterns using cull: in pharo more often than not are very poorly documented about the arguments that are given to the block). > > Smalltalk is disruptive enough as it is (and still is after all those years) to try not to make it more complex. I'd prefer efforts making obvious really complex patterns instead of idioms with a not so great cognitive load to effectiveness. > > I'd be happy to have a shorter list of methods and extensions on Object, as well :) > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Goubier Thierry

Le 18/06/2013 12:27, Camille Teruel a Ã©crit : > > On 18 juin 2013, at 11:20, Goubier Thierry wrote: > >> Hi Camille, >> >> It's not bad as things goes, because it does look a bit like >> non-smalltalk code (i.e. the if then else structure) except that the >> precise meaning is very much Smalltalk : > > Ok the name may be confusing. > So if you rename it to something like #if:do:elseDo:, it would be more > smalltalkish and there is no confusion with classical if-then-else. Maybe, that would help. >> if: has a receiver, and there is a not so intuitive relationship >> between the bloc parameters and the receiver. > > Talking to an arbitrary object is the goal, since booleans are not very > talkative kind of object. > Compare > > | temp | > temp := <complexExpression> > temp isNil ifTrue: [...] ifFalse: [... temp ...] > > with: > > <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] > > ifNil:ifNotNil: is not better only because it is shorter, it is better > because I am talking to the object I am auditing, not a stupid boolean > that knows nothing else but its truth value. Yes, but I know firsthand (because I used Smalltalk before that idiom was introduced) that it represent one more idiom to learn, and it's still not familiar. The same goes with withStreamDo: or what is that idiom again I sometimes encounter. >> Honestly, as far as code reviews goes, I'll prefer the temp >> refactoring. Understandable without having to search for the >> implementors of #if:then:else: > > I know this would break a long time tradition and people may not like > it, so that's a question of taste and style, not understandability. > There would be only one implementor, the implementation is really simple > and the selector is explicit. > Anyone can get use to it in less than 2 min. It's one more thing to get used to and to explain to beginners in say 10 minutes per idiom... (describe, give an example, let them practice, rinse and repeat for each idiom). Add all the new idioms and, instead of explaining Smalltalk in half a day, you spend a few days doing explaining all those idioms and not doing more interesting stuff. Soon, you end up like ocaml, where your minimum introduction time is a week, not half a day. > Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: > ,... every time? > No because people learned what they do when they learned Smalltalk, and > I'm sure it didn't get them more than a few minutes. Yes, but add the ifNil: ifNotNil:, stream thingies I never remember, your variant of if-else, and, and ... On some of those, I have to look for the implementors, and I'm really happy to benefit from the smart suggestions in the new browsers. (Additionally, code patterns using cull: in pharo more often than not are very poorly documented about the arguments that are given to the block). Smalltalk is disruptive enough as it is (and still is after all those years) to try not to make it more complex. I'd prefer efforts making obvious really complex patterns instead of idioms with a not so great cognitive load to effectiveness. I'd be happy to have a shorter list of methods and extensions on Object, as well :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 18, 2013

Re: [Pharo-dev] Changing ConfigurationOfCog

by Esteban Lorenzano

well... afaik, no one outside pharo community is using the configurations, the other guys on vm-dev prefer the old way of doing things. also, the group "pharo" is intended to include the things necessary to produce a "pharo vm"... this is what time ago was in the ConfigurationOfPharoVM. That means: you can produce a CogVM without loading group "pharo", but not a Pharo VM. Esteban On Jun 18, 2013, at 10:26 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi guys! > > I worked yesterday on making VMMaker load and work in Pharo2.0 with filesystem. Now, I want to push my changes in a new development version of ConfigurationOfCog. But I have some questions: > > Is ConfigurationOfCog used by other people besides Pharo? > > Because so far I see: > - there are two different groups in the conf: #common and #pharo. > - In #common, there is CMakeVMMaker (which in turn loads cairo from files.pharo.org :)) and the oscog branch of VMMaker. Both have only as latest committers Igor and Esteban :P. And I > - in #pharo there are nativeboost and some compatibility packages. > > So there are pharo specific stuff in both groups, or am I mistaken? Should we keep both groups, or make them one and simplify? And how should I push my changes related with filesystem (pharo-specific) then? > > Guille

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Camille Teruel

On 18 juin 2013, at 11:20, Goubier Thierry wrote: > Hi Camille, > > It's not bad as things goes, because it does look a bit like non-smalltalk code (i.e. the if then else structure) except that the precise meaning is very much Smalltalk : Ok the name may be confusing. So if you rename it to something like #if:do:elseDo:, it would be more smalltalkish and there is no confusion with classical if-then-else. > if: has a receiver, and there is a not so intuitive relationship between the bloc parameters and the receiver. Talking to an arbitrary object is the goal, since booleans are not very talkative kind of object. Compare | temp | temp := <complexExpression> temp isNil ifTrue: [...] ifFalse: [... temp ...] with: <complexExpression> ifNil: [ ... ] ifNotNil: [ :obj | ... obj ...] ifNil:ifNotNil: is not better only because it is shorter, it is better because I am talking to the object I am auditing, not a stupid boolean that knows nothing else but its truth value. > Honestly, as far as code reviews goes, I'll prefer the temp refactoring. Understandable without having to search for the implementors of #if:then:else: I know this would break a long time tradition and people may not like it, so that's a question of taste and style, not understandability. There would be only one implementor, the implementation is really simple and the selector is explicit. Anyone can get use to it in less than 2 min. Do everyone verify the implementors of do: , collect: , ifTrue:ifFalse: ,... every time? No because people learned what they do when they learned Smalltalk, and I'm sure it didn't get them more than a few minutes. > > Regards, > > Thierry > > Le 18/06/2013 10:51, Camille Teruel a Ã©crit : >> Hello everyone. >> >> I see a lot of code that follows the following pattern: >> >> <a long expression> <aComplexTest> >> ifTrue: [ <a long expression> <something> ] >> ifFalse: [ <a long expression> <something else> ]. >> >> The classic refactoring is to store <a long expression> in a temp to >> avoid repetition: >> >> | temp | >> temp := <a long expression>. >> temp <aComplexTest> >> ifTrue: [ temp <something> ] >> ifFalse: [ temp <something else> ]. >> >> Then <a long expression> is evaluated once and the name of the temp can >> carry a meaningful name that helps reading the code. >> But this is more verbose than the first version. >> But if you add the following method in Object: >> >> if: conditionBlock then: trueBlock else: falseBlock >> ^ (conditionBlock cull: self) >> ifTrue: [ trueBlock cull: value ] >> ifFalse: [ falseBlock cull: value ] >> >> You can then rewrite it like that: >> >> <a long expression> >> if: [ :obj | obj <aComplexTest> ] >> then: [ :obj | <something> ] >> else: [ :obj | <something else> ] >> >> The names of the block args can give a meaningful name depending on the >> result of the test (something like ... if: #notEmpty then: [ :collection >> | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three >> block also enable a good flexibility: you can omit the arg when irrelevant. >> >> Likewise, we could also have Object>>#while:do: >> >> while: conditionBlock do: actionBlock >> ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] >> >> What do you think? >> >> Camille > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Camille Teruel

On 18 juin 2013, at 11:10, StÃ©phane Ducasse wrote: > is it not slower? Yes a bit slower. > and I would remove as much as method as possible from Object. > > why >> | temp | >> temp := <a long expression>. >> temp <aComplexTest> >> ifTrue: [ temp <something> ] >> ifFalse: [ temp <something else> ]. > > is not good enough? If it is the whole content of a method it is good. But in complex methods you end up with a bunch of temps that do are not needed and that decrease readability. > > And finally we should kill as much as possible of these ifâ¦. so > > >> Hello everyone. >> >> I see a lot of code that follows the following pattern: >> >> <a long expression> <aComplexTest> >> ifTrue: [ <a long expression> <something> ] >> ifFalse: [ <a long expression> <something else> ]. >> >> The classic refactoring is to store <a long expression> in a temp to avoid repetition: >> >> | temp | >> temp := <a long expression>. >> temp <aComplexTest> >> ifTrue: [ temp <something> ] >> ifFalse: [ temp <something else> ]. >> >> Then <a long expression> is evaluated once and the name of the temp can carry a meaningful name that helps reading the code. >> But this is more verbose than the first version. >> But if you add the following method in Object: >> >> if: conditionBlock then: trueBlock else: falseBlock >> ^ (conditionBlock cull: self) >> ifTrue: [ trueBlock cull: value ] >> ifFalse: [ falseBlock cull: value ] >> >> You can then rewrite it like that: >> >> <a long expression> >> if: [ :obj | obj <aComplexTest> ] >> then: [ :obj | <something> ] >> else: [ :obj | <something else> ] >> >> The names of the block args can give a meaningful name depending on the result of the test (something like ... if: #notEmpty then: [ :collection | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three block also enable a good flexibility: you can omit the arg when irrelevant. >> >> Likewise, we could also have Object>>#while:do: >> >> while: conditionBlock do: actionBlock >> ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] >> >> What do you think? >> >> Camille >

June 18, 2013

Re: [Pharo-dev] Object>>#if:then:else:

by Igor Stasenko

On 18 June 2013 11:20, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Camille, > > It's not bad as things goes, because it does look a bit like non-smalltalk > code (i.e. the if then else structure) except that the precise meaning is > very much Smalltalk : > > if: has a receiver, and there is a not so intuitive relationship between the > bloc parameters and the receiver. > > Honestly, as far as code reviews goes, I'll prefer the temp refactoring. > Understandable without having to search for the implementors of > #if:then:else: > +1 > Regards, > > Thierry > > Le 18/06/2013 10:51, Camille Teruel a Ã©crit : > >> Hello everyone. >> >> I see a lot of code that follows the following pattern: >> >> <a long expression> <aComplexTest> >> ifTrue: [ <a long expression> <something> ] >> ifFalse: [ <a long expression> <something else> ]. >> >> The classic refactoring is to store <a long expression> in a temp to >> avoid repetition: >> >> | temp | >> temp := <a long expression>. >> temp <aComplexTest> >> ifTrue: [ temp <something> ] >> ifFalse: [ temp <something else> ]. >> >> Then <a long expression> is evaluated once and the name of the temp can >> carry a meaningful name that helps reading the code. >> But this is more verbose than the first version. >> But if you add the following method in Object: >> >> if: conditionBlock then: trueBlock else: falseBlock >> ^ (conditionBlock cull: self) >> ifTrue: [ trueBlock cull: value ] >> ifFalse: [ falseBlock cull: value ] >> >> You can then rewrite it like that: >> >> <a long expression> >> if: [ :obj | obj <aComplexTest> ] >> then: [ :obj | <something> ] >> else: [ :obj | <something else> ] >> >> The names of the block args can give a meaningful name depending on the >> result of the test (something like ... if: #notEmpty then: [ :collection >> | ... ] else: [ :emptyCollection | ... ]). Using cull: for the three >> block also enable a good flexibility: you can omit the arg when >> irrelevant. >> >> Likewise, we could also have Object>>#while:do: >> >> while: conditionBlock do: actionBlock >> ^ [ conditionBlock cull: self ] whileTrue: [ actionBlock cull: self ] >> >> What do you think? >> >> Camille > > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > -- Best regards, Igor Stasenko.

June 18, 2013