Re: [Pharo-project] about ifEmptyOrNil:
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: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
pennell.david@gmail.com 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 <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
I think it's reasonable to ditch it. Its just syntactic sugar (and should have probably been named ifNilOrEmpty). -david On Mon, Oct 6, 2008 at 6:28 AM, Bill Schwab <BSchwab@anest.ufl.edu> wrote:
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: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
pennell.david@gmail.com 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 <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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Bill Schwab -
David Pennell