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 <estebanlm@gmail.com> 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 <stephane.ducasse@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