Yes sorry I was in the train and this is isEmptyOrNil:

I don't have an ifEmptyOrNil: in my image only isEmptyOrNil and that is specified for Collection and UndefinedObject.

Did I miss something?

No

I agree with Lukas, and the other comments on the naming that really you imply a test for nil first before the empty. My experience with coming across and recalling heavy usage is that the receiver is always a String. I took it to be a convenience (laziness) for typing the longer form during string processing that is perhaps written in a procedural manner. If the receiver is treated like a collection, i.e. using do: select: etc then an empty collection is a fine null object. Don't mind it being dropped, but perhaps it could remain on String? Is the convenience justified? thanks, Mike On Mon, Oct 6, 2008 at 9:35 PM, nicolas cellier <ncellier@ifrance.com> wrote:

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Oct 6, 2008, at 11:28 PM, Michael Roberts wrote:

I agree with Lukas, and the other comments on the naming that really you imply a test for nil first before the empty. My experience with coming across and recalling heavy usage is that the receiver is always a String. I took it to be a convenience (laziness) for typing the longer form during string processing that is perhaps written in a procedural manner. If the receiver is treated like a collection, i.e. using do: select: etc then an empty collection is a fine null object. Don't mind it being dropped, but perhaps it could remain on String? Is the convenience justified?

I can imagine that there are some cases where you want to make a distinction between no result and empty result from an UI perspective. But I learned something from this thread. And probably we should deprecated it. stef

Just today I was loading objects from an ODBCRow and wrote a: Collection>>addIfNotNilOrBlank ! Like you said...sometimes you get '', sometimes you get nil! Take care, Rob On Tue, Oct 7, 2008 at 6:02 PM, Keith Hodges <keith_hodges@yahoo.co.uk>wrote:

When I think about this issue in different terms I think it makes more sense. No matter how perfect my code I find myself interfacing to things like MySQL where it is happy to return nil when it means an empty string.

someValue ifNotUsefulUse: [ defaultValue ].

but then the question "what does useful mean", at which point it becomes easier to define clearly what is not useful i.e.

someValue ifNilOrEmpty: [ defaultValue ].

If I had known this call existed I would use it much more because

b := someValue ifEmpty: [ defaultValue ].

doesnt work (see earlier discussions on squeak-dev)

regards

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Tue, 07 Oct 2008 23:54:02 +0100 Keith Hodges <keith_hodges@yahoo.co.uk> wrote:

After all purists don't have to interface to databases... do they?

Or users: +-----------------------------------+ | | | Please enter your comment: | | | | __________________________ | | | | Ok Cancel | +-----------------------------------+ s.