Stéphane Ducasse <stephane.ducasse@...> writes:
Hi
I would like to have your take on that one:
isEmpty "Answer whether the receiver contains any elements."
^self size = 0
Why do we need ifEmptyOrNil:
isEmptyOrNil "Answer whether the receiver contains any elements, or is nil. Useful in numerous situations where one wishes the same reaction to an empty collection or to nil" ^ self isEmpty
why can we use isEmpty: or ifEmpty: aBlock
ifEmpty: aBlock "Evaluate the block if I'm empty" ^ self isEmpty ifTrue: aBlock
Then from an implementation point of view ifEmptyOrNil: is bogus since it never returns nil (or should not and is also ill-specified). I checked ANSI and this is really a boolean.
I'm the mood to deprecate this method. Stef
Seriously, why should this message return nil? Isn't the meaning clear? isEmpty or isNil. Or do you suggest UndefinedObject should implement #isEmpty and #ifEmpty: ? Now what are the advantages over (x isNil or: [x isEmpty])? - can be used on an arbitrary expression without storing in a temp - a tiny performance improvement if ever used in a tight loop. Very limited indeed, and not a good candidate for a tiny kernel. With this light, I better understand your mood. The arguments to not remove it are inertia as usual. I see 163 senders in the 10074 image and probably many more in Squeak packages. Le ver est dans le fruit. If you want to remove such message, it would be good to have a base of refactoring rules to be applied on Squeak packages so that they become Pharo friendly. Sort of one-click compatibility automaton. Cheers