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 <[EMAIL PROTECTED]> 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: [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 > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
