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 >
