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?
--
Simon
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
