"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?
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 >> > > >
