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). Phil On Mon, Jan 5, 2015 at 2:43 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should *not be nil or an empty string*.
Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should *not* be nil or an empty collection.
About #thing being meaningless, sure, Iâve mentioned as general example. I donât see that every user of #thing *has* to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued *if* none is found which is expressed in the completely sensible form of receiving nil or an empty collection :)
Thanks for giving it a thought
On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 05.01.2015 um 14:01 schrieb Sebastian Sastre < sebastian@flowingconcept.com>:
On Jan 5, 2015, at 10:38 AM, phil@highoctane.be wrote:
In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though).
Totally. In real apps, having to compare against uninitialized variable or nil as response or empty string happens so often that having this method makes it quite convenient (AKA lots of code becomes one-liners).
We could use
x := [ self thing ] ifError: [ someDefault ]
I understand youâre setting a similar, quite not like it example but in any case this one raises and catches an exception and that sounds quite less efficient if compared to return self (when object is not nil and is not an empty collection/string)
for these purposes. Triggering errors is not too nice still.
Now, what if self itself is nil or empty?
BTW, isEmptyOrNil exists in the image for Collections and UndefinedObject. Empty has no meaning for Object, so why test against empty in the name?
Note that is not a testing method, itâs a conditional executor of the closure. The reason why was already mentioned, is to allow you to write this one-liner convenience: someVar := self thing ifNilOrEmpty: [blah]
`self thing` could be an expensive process that returns something or nil or an empty collection. *If* you get nil or empty as result then you would get the block values resulting in having blah at someVar
In the image, I see that we do have #default: anObject in several places. It seems to serve the same intent.
What is the idiom for such things in Pharo? Importing idioms from other languages works but if we do have one already, we will introduce confusion.
how can you do that one-liner without introducing *ifNilOrEmpty:* ?
What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way.
my 2 cents,
norbert
Phil
On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
This is not about taste. This is about not promoting the use of nil or dependency or the meaning of empty collection.
A better way is to look at the upstream logic and modify that one so that it does not need to know about nil or empty.
Cheers, Doru
On Mon, Jan 5, 2015 at 1:17 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
taste is taste but would you care to illustrate your point with examples? Iâm curious about it
On Jan 5, 2015, at 6:12 AM, stepharo <stepharo@free.fr> wrote:
You summarise well the kind of code I do not like. isNil everywhere and horrible tests.
Stef
Le 4/1/15 23:27, Sebastian Sastre a écrit :
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 :)
-- www.tudorgirba.com
"Every thing has its own flow"
-- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium
Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller