On Mon, Jan 5, 2015 at 3:04 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

El Mon Jan 05 2015 at 10:50:48 AM, phil@highoctane.be <phil@highoctane.be> 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,