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.nice@gmail.com> wrote:
2010/7/2 Simon Denier <Simon.Denier@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