On 5 mar 2010, at 09.33, Fernando olivero <oliverof@lu.unisi.ch> wrote:
The problem is the side effects, is suddenly Boolean>>and: stops to be lazy. Possibly evaluating blocks that shouldn't be evaluated.
No, but there is one subtle difference anyway: both #and: and #or: will return a Boolean (the receiver) if the block argument isn't executed, whereas #ifTrue: and #ifFalse: will return nil in that case. So if you do something with the return value, then the bytecode will be different for sure. But it's academic anyway: the use of #and: and #or: gives the reader a very strong hint that the argument block (if executed) is supposed to return a Boolean, so to use it purely for branching in the code could be seen as misleading. -- Cheers, Peter
Fernando
On Mar 5, 2010, at 8:22 AM, Igor Stasenko wrote:
Hello, I just realized, that one can completely avoid using ifTrue/ifFalse branches, but use #or: and #and: instead.
a > b ifTrue: [ ... ] could be written as: a > b and: [ ... ]
a > b ifFalse: [ ... ] could be written as: a > b or: [ ... ]
and a > b ifTrue: [ self foo ] ifFalse: [ self bar ] could be written as:
a > b and: [ self foo]; or:[ self bar ]
:)
-- 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