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. 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
