FWIW, I long ago defined a method #isNonTrivial that has meaning in various places, e.g. for TimeStamp. Having a method to express the concept of being non trivial (not nil, not empty, etc.) is more powerful and flexible than hard coding/duplicating tests in many locations.
Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Stéphane Ducasse [[email protected]] Sent: Wednesday, July 20, 2011 2:04 PM To: [email protected] Subject: Re: [Pharo-project] why isEmptyOrNil is not defined in Object? On Jul 19, 2011, at 2:57 PM, Nicolas Cellier wrote: > "deprecate it" was a bit provocative, and would be hard to achieve now. > But you agree that we gratuitously complexified a legacy simple interface, > while there were smoother, and IMO more elegant solutions, don't you? probably. Now we can deprecate it. I think that this is important to have a process and state of mind that ack that errors are not a problem but a way to learn (even if this is a slower way than doing right the first time). > Nicolas > > 2011/7/19 Esteban Lorenzano <[email protected]> > well... I use it a lot... yes, mainly for "FillInTheBlank". > In fact, I usually add it to my programs... > however, I'm not sure if we have to deprecate it (and replace for a larger > code), or adopt it :) > > cheers, > Esteban > > El 19/07/2011, a las 7:14a.m., Nicolas Cellier escribió: > >> I don't like isEmptyOrNil. >> It has been introduced mainly because we can now distinguish these two >> operations in a "FillInTheBlank" >> - cancel returns nil >> - accept returns a String eventually empty >> The original implementation did always return an empty String even if cancel >> was pressed. >> >> But no application is really prepared to deal with nil, and most did >> interpret an empty String as a cancel. >> So we replaced the isEmpty checks by isEmptyOrNil... >> >> I would have done it differently: >> 1) let the default return an empty String even if cancelled >> 2) provide a ifCancelled: addtional key for the rare apps which really need >> to distinguish. >> >> UIManager default request: 'OK ?' initialAnswer: '' ifCancelled: [^nil]. >> >> Default behaviour would be equivalent to >> UIManager default request: 'OK ?' initialAnswer: '' ifCancelled: ['']. >> >> So my take would be to deprecate it. >> >> Nicolas >> >> 2011/7/19 Stéphane Ducasse <[email protected]> >> Hi guys >> >> I'm puzzled and probably need food. but why isEmptyOrNil is not defined in >> Object? >> because right now if a variable is '' or nil or something else I cannot use >> it. >> >> Stef >> > >
