100% agreement on this 2010/7/3 Eliot Miranda <eliot.mira...@gmail.com>: > Hi Nicolas, > in any case the comment needs to specify that behavior, e.g. > Collection>>ifNotEmpty: aBlock > "Evaluate the given block with the receiver as argument, answering its > value > unless the receiver is empty, in which case answer the receiver." > ^self isEmpty > ifTrue: [self] > ifFalse: [aBlock valueWithPossibleArgument: self] > > and in this case IMO the explicit return self is better than the implicit > one. > On Fri, Jul 2, 2010 at 2:34 PM, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com> wrote: >> >> 2010/7/2 Simon Denier <simon.den...@inria.fr>: >> > 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 >> > 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 > > > _______________________________________________ > 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
