Re: [Pharo-project] why isEmptyOrNil is not defined in Object?

[Stéphane Ducasse]

I see. I remember the story. For me I find that it does not really help to deal with crappy code = timestamp in methodReference which can be a timestamp nil or '' (do not ask me why). Now I think that this is important to distinguish from the UI between cancel and stupid default. Normally default should be meaningful. 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. I have the impression too. We should evaluate the impact and do it. Nicolas 2011/7/19 Stéphane Ducasse <stephane.duca...@inria.fr> 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