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 >
