David,
I first heard of defensive programming in the spirit of getting around
the dreaded UAE of the pre-exceptions world of Windows. My sense was
that it didn't stick for a few reasons: (1) 32 bit address spaces
greatly reduced the need for creative memory management, all but
eliminating a gratuitous source of human error ; (2) even more
important, the arrival of structured exception handling along with the
32 bit pointers; (3) in many situations, defensive programmer (as I
understand it) is a formalization for creating programs that suppress
their problems vs. dealing with them. I tried it with numerical
analysis code in that same era, and very quickly discovered that it was
better to have a crash than garbage results.
There are of course times when a crash is intolerable, and I especially
do not think we should dictate our ideas of aesthetics (one of my main
gripes about Squeak). I am inclined to vote against this one, but it
there is interest in keeping it, I suppose it is better to code it once
correctly than to force people to inline it and maybe botch it.
However, I can also argue that #isNil and #isEmpty both exist, and
( x isNil or:[ x isEmpty ] ) ifTrue:[
"run for the hills"
].
is not ambiguous. In most situations, an empty collection is not a
threat - iterating it seldom hurts. Like I said, I'm inclined to vote
this one down, but won't start a battle over 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/05/08 9:47 PM >>>
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 <[EMAIL PROTECTED]>
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: [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
>
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
