Re: [Pharo-project] about ifEmptyOrNil:
Stef, I suspect your mood is appropriate. Most likely, it masks a failure to initialize something to a collection. Unless there is a performance argument (e.g. many are created, few are actually used, or something like that??), then it probably should go. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/05/08 5:31 AM >>> 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I would expect to see another implementation of ifEmptyOrNil on UndefinedObject that returns true. I've seen it used productively for defensive coding in frameworks, where you may get nil instead of an empty collection passed to you. -david On Sun, Oct 5, 2008 at 8:28 PM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
Stef,
I suspect your mood is appropriate. Most likely, it masks a failure to initialize something to a collection. Unless there is a performance argument (e.g. many are created, few are actually used, or something like that??), then it probably should go.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
stephane.ducasse@inria.fr 10/05/08 5:31 AM >>> 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
_______________________________________________ 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
On Oct 6, 2008, at 3:47 AM, David Pennell wrote:
Stef,
I would expect to see another implementation of ifEmptyOrNil on UndefinedObject that returns true. I've seen it used productively for defensive coding in frameworks, where you may get nil instead of an empty collection passed to you.
Hi david Good suggestion. I learned something. UndefinedObject>>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" ^ true I still find that somehow ugly. Fixing the cause not the problem. Stef
There is a typical usage fileOutSoundLibrary: aDictionary "File out the given dictionary, which is assumed to contain sound and instrument objects keyed by their names." "Note: This method is separated out so that one can file out edited sound libraries, as well as the system sound library. To make such a collection, you can inspect AbstractSound sounds and remove the items you don't want. Then do: 'AbstractSound fileOutSoundLibrary: self' from the Dictionary inspector." | fileName refStream | fileName := UIManager default request: 'Sound library file name?'. fileName isEmptyOrNil ifTrue: [^ self]. refStream := SmartRefStream fileNamed: fileName, '.sounds'. refStream nextPut: aDictionary. refStream close. which could make sense. Now I saw some other places where this is way to avoid to be precise. Stef On Oct 6, 2008, at 8:28 AM, Stéphane Ducasse wrote:
On Oct 6, 2008, at 3:47 AM, David Pennell wrote:
Stef,
I would expect to see another implementation of ifEmptyOrNil on UndefinedObject that returns true. I've seen it used productively for defensive coding in frameworks, where you may get nil instead of an empty collection passed to you.
Hi david
Good suggestion. I learned something.
UndefinedObject>>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" ^ true
I still find that somehow ugly. Fixing the cause not the problem.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
which could make sense. Now I saw some other places where this is way to avoid to be precise.
Even if slightly longer, I find the following expression more readable a isNil or: [ a isEmpty ] than a isEmptyOrNil Especially with the long form I know at one glance what it *exactly* does. I don't think it is an advantage to introduce hundreds of control structures with unclear semantics. These things make porting code very hard too. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (4)
-
Bill Schwab -
David Pennell -
Lukas Renggli -
Stéphane Ducasse