thanks for the discussion! http://code.google.com/p/pharo/issues/detail?id=2636
Stef On Jul 3, 2010, at 9:04 AM, Nicolas Cellier wrote: > 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
