> On 05 Jan 2015, at 3:46 , Sebastian Sastre <sebast...@flowingconcept.com> > wrote: > > >> On Jan 5, 2015, at 12:07 PM, Henrik Johansen <henrik.s.johan...@veloxit.no >> <mailto:henrik.s.johan...@veloxit.no>> wrote: >> >> >>> On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebast...@flowingconcept.com >>> <mailto:sebast...@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
