On 05 Jan 2015, at 3:46 , Sebastian Sastre <sebastian@flowingconcept.com> wrote:
On Jan 5, 2015, at 12:07 PM, Henrik Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote:
On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebastian@flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote:
but not putting it on Object would change the feature since you do want it returning self on that case.
No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object >> ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to "are you a collection or single instance?" checks in almost every user of said variable.
Hi Henry,
I think you are talking of a different feature or maybe promoting that things should not be treated as possibly nil or empty collections which is understandable but Iâm treating the programers as good citizens that know what they do and bear the consequences (not as beasts that should be educated or indoctrinated or prevented on how to use code and do things)
No, I'm talking about exactly what I quoted, implementing ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. Doing that is not about indoctrinating, but preventing bad code resulting from using the same variable to hold non-polymorphic objects.
Whatever the case does your idea pass this test?
testIfNilOrEmpty
| stuff thing |
stuff := nil.
self assert: stuff equals: nil. self assert: thing equals: nil. thing := stuff ifNilOrEmpty: [ 42 ]. self assert: thing equals: 42.
stuff := 1984. thing := stuff ifNilOrEmpty: [ 42 ].
self deny: thing = nil. self assert: thing equals: 1984. self deny: thing = 42.
Of course, since my idea was to use ifNil: when the variable you are dealing with is not Collections. Cheers, Henry