Strings, eh??? Now this makes more sense. I have defined some methods named #isNonTrivial that I use in some "defensive" situations (ok, a few are quite simly cowardly<g>), all the way up to decisions about how to represent chunks of medical records. Most senders are of the latter type. Looking at it that way, I'm less bothered by it, but the name is not all that inspiring.
However, my biggest gripes about Squeak has been the "you can't do that because I think it's ugly" thinking, so far be it from me to try to insist it go. I suggest nudging it toward #isNonTrivial if you want to keep it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [EMAIL PROTECTED] Tel: (352) 273-6785 FAX: (352) 392-7029 >>> [EMAIL PROTECTED] 10/6/2008 4:28 PM >>> 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 > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
