[Pharo-project] why isEmptyOrNil is not defined in Object?
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
I would say for the same reason #isEmpty is not defined on Object, but only on Collection. #isEmptyOrNil is the equivalent of obj isNil or: [ obj isEmpty ] (which i find clearer and) which doesn't work on arbitrary objects either. Lukas On Tuesday, 19 July 2011, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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
-- Lukas Renggli www.lukas-renggli.ch
On Jul 19, 2011, at 12:08 PM, Lukas Renggli wrote:
I would say for the same reason #isEmpty is not defined on Object, but only on Collection. #isEmptyOrNil is the equivalent of
obj isNil or: [ obj isEmpty ]
yes this is what I did. I do not see the point of isEmptyOrNil just because people returns nil or '' while a default decent value should be returned.
(which i find clearer and) which doesn't work on arbitrary objects either.
Lukas
On Tuesday, 19 July 2011, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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
-- Lukas Renggli www.lukas-renggli.ch
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
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
"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 <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
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
FWIW, I long ago defined a method #isNonTrivial that has meaning in various places, e.g. for TimeStamp. Having a method to express the concept of being non trivial (not nil, not empty, etc.) is more powerful and flexible than hard coding/duplicating tests in many locations. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, July 20, 2011 2:04 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why isEmptyOrNil is not defined in Object? 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
participants (6)
-
Esteban Lorenzano -
Lukas Renggli -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse -
Stéphane Ducasse