but not putting it on Object would change the feature since you do want it returning self on that case.

But from your comment we can take the idea of adding it in Object, UndefinedObject and Collection and it will be a faster implementation since it will be trivial for the three of them, no?



On Jan 4, 2015, at 8:40 PM, Benoit St-Jean <bstjean@yahoo.com> wrote:

A cleaner implementation would be to define this method in UndefinedObject and Collection only.  It should not appear in Object, the same way #isEmptyOrNil is defined.
 
-----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
IRC: lamneth
Blogue: endormitoire.wordpress.com

"A standpoint is an intellectual horizon of radius zero".  (A. Einstein)

From: Sebastian Sastre <sebastian@flowingconcept.com>
To: Pharo Development List <pharo-dev@lists.pharo.org>
Sent: Sunday, January 4, 2015 5:27 PM
Subject: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

Hi guys,

I���ve started to use this little one:

Object>>ifNilOrEmpty: aBlock

    self ifNil: [ ^ aBlock value ].
   
    (self isCollection and: [
    self isEmpty ]) ifTrue: [ ^ aBlock value ].

    ^ self.


It allows you to do the widely known JavaScript one-liner:

var stuff = this.thing || ���some default value for when this.thing is undefined, null or an empty string���.

but in smalltalk in this way:

stuff := self thing ifNilOrEmpty: [ ���some default value for when self thing is nil or an empty string��� ]

simple thing feels practical and nice :)