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 <siguctua@gmail.com>:
On 26 May 2010 15:16, Stéphane Ducasse <stephane.ducasse@inria.fr> 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.ht... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project