On 5 mar 2010, at 09.33, Fernando olivero <[email protected]> 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 >> [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
