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 <[EMAIL PROTECTED]> wrote: > Stéphane Ducasse <[EMAIL PROTECTED]> 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
