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: [EMAIL PROTECTED]
Tel: (352) 273-6785
FAX: (352) 392-7029
>>> [EMAIL PROTECTED] 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
