On Mon, Jan 5, 2015 at 3:04 PM, Esteban A. Maringolo <[email protected]> wrote:
> > El Mon Jan 05 2015 at 10:50:48 AM, [email protected] <[email protected]> > escribió: > >> Why not put that into a Trait? >> >> TDefaultValueIdiom>>ifEmptyOrNil: aDefaultObject >> >> So, if wanted,, one can put "uses TDefaultValueIdiom" (I am at a loss for >> a great name here, help!) and do as Sebastian proposes. >> >> This will prevent pollution of Object while at the same time being able >> to have the idiom available (and maybe with more than one form). >> >> > But you can't "hot plug" a Trait to Object to have this behavior > system-wide. Adding a trait involves recompilation AFAIR. > Well, adding a Trait to Object doesn't work (dangerous change). But we can add that to objects we do control. Which may be good enough. P. > > The only thing I'd argue against is the naming. > Otherwise is a very convenient method, when you go outside of the > Smalltalk island and interact with API's not very well crafted or desgned > to err on the "safe" side (empty collections instead o null), asking > whether an object isNull or empty in the same method is really convenient. > > If we get purists, nil shouldn't exist either [1] and they should be > replaced by domain specific abstractions representing the void/undefined. > But we know there is a use case for nil, as IMO, there is a use case for > isEmptyOrNil. > > However, whether you add it to Object in Pharo core image or not isn't > really relevant, whoever wants/needs it can add it afterwards. > > Regards, > > [1] > http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare > >
