Another point that I feel is important for banning and:and:... is that it makes code harder to refactor.
Consider: #1: exp1 and: [exp2] and: [exp3] and #2: (exp1 and: [exp2]) and: [exp3] In #2, I can select what is inside (...) and press extract to method. In #1, I cannot select "exp1 and: [exp2]" and extract. The rb engine will not like it. And I would not expect the rb engine to extract piece of a message call into a new method. Cheers, Alexandre On 26 May 2010, at 12:16, Nicolas Cellier wrote: > Lukas already answered very well. > From core designer point of view, the questions is what additionnal > value is brought by #and:and:and: ? > - does it add expressiveness against nested and: [and: [ and: [ ] ] ] ? Not > much > - does it shorten code ? No > - does it enable some optimization ? No > If it has no value, then we should better remove it and simplify the API. > > Nicolas > > 2010/5/26 Igor Stasenko <[email protected]>: >> On 26 May 2010 15:16, Stéphane Ducasse <[email protected]> wrote: >>> In general (but it often does not work :)) having a lot of conditions in OOP >>> means that you are missing class to dispatch on then. >>> >> Yup. Another argument to kill and:and:and: >> It reminds me >> isKindOf:orOf: >> >>>> But then which is the equivalence to #and:and:and: when I have many >>>> conditions? >>> >>> a and: [b] and: [c] >>> >>> if a and c do not have side effect that may change the condition are >>> equivalent >>> to >>> a and: [ b and: [c]] >>> >>> so you have express what you want >>> >>>> Perhaps I will say a stupidity... but , not is valid the implementation of >>>> #&& and #|| messages instead of #and:... #or: .....? >>> >>> >>> & and | are executing all their arguments while >>> true & error -> error >>> true and: [error] -> true but it is more costly >>> >>> >>>> >>>> ( aCondition1 && aCondition2 && aCondition3 ) ifTrue: [ <something> ] >>>> >>>> >>>> Regards >>>> -- >>>> View this message in context: >>>> http://forum.world.st/and-and-and-deprecated-on-1-1-why-tp2230786p2231486.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
