2010/7/2 Simon Denier <[email protected]>: > I just noticed that the semantic of Collection>>ifNotEmpty: has changed in > subtle ways between Pharo 1.0 and 1.1 > > In 1.0 > Collection>>ifNotEmpty: aBlock > "Evaluate the given block unless the receiver is empty. > > If the block has an argument, eval with the receiver as its argument, > but it might be better to use ifNotEmptyDo: to make the code easier to > understand" > > ^self isEmpty ifFalse: [aBlock valueWithPossibleArgument: self]. > > -----> it returns nil if collection is empty > > > in 1.1 > Collection>>ifNotEmpty: aBlock > "Evaluate the given block unless the receiver is empty. > > If the block has an argument, eval with the receiver as its argument, > but it might be better to use ifNotEmptyDo: to make the code easier to > understand" > > self isEmpty ifFalse: [^ aBlock valueWithPossibleArgument: self]. > > ----> the return is inside the block, now it returns the collection if > collection is empty > > > Apparently all similar code (#ifEmpty:....) has been adapted in the same way. > > Of course I would not have stumbled upon this change if it didn't break some > of my code which rely on the previous assumption. > > Now I would like to understand before making some change in my code. Is it > considered bad practice to return nil in such cases? What is the rationale to > return yourself instead of nil? >
The new version is better because: - it is homogeneous with ifNil: behaviour - it enables writing: self classifyMethodAs: (myProtocol ifEmpty: ['As yet unclassified']) Nicolas > -- > Simon > > > > _______________________________________________ > 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
