Hi, As discussed in this thread, I do not see a reason for implementing this method in Object.
Having it in Collection/UndefinedObject can make some sense (although I do not really like it) for working with variables that can be either collection or nil. Cheers, Doru On Mon, Jan 5, 2015 at 8:59 PM, Esteban Lorenzano <[email protected]> wrote: > in any case, we already have the idiom #isEmptyOrNil (btw, in pharo4 it > was removed from Object and I don’t know why, but is still in Collection > and in UndefinedObject). > So, in case of adding it, the correct implementation should be: > > 1) restore Object>>#isEmptyOrNil ^ false > 2) implement: > > Object>>#ifEmptyOrNil: aBlock > self isEmptyOrNil ifTrue: aBlock. > ^ self > > which IMO is the clean way to implement such idiom. > > said that, I will go back to my vacations :) > > Esteban > > > > On 05 Jan 2015, at 15:47, Esteban A. Maringolo <[email protected]> > wrote: > > El Mon Jan 05 2015 at 3:36:50 PM, stepharo <[email protected]> escribió: > >> >> This is not because some people may not know how to program in other >> languages that we should copy that. >> > > I share your "taste" for this kind of code. > > But this purist approach raises the bar leaving out a lot of developers > with poor design/modelling skills. The more 1:1 mappings they can bring in > from their previous language of choice, the better, and higher the odds > they'll clinge on Pharo and continue using it. > > To make both "sides" of this discussion happy I think the base image > shouldn't include this, and there can be an extra package with these > "language" extensions. > > Regards! > > > > -- www.tudorgirba.com "Every thing has its own flow"
