2 Jul
2010
2 Jul
'10
9:10 p.m.
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