Guys
Do you think that Pharo does not have the complexity of a real app? :)
Now seriously if you have to deal with external values, then this is the
job of the importer to import and put polymorphic
default in variable. Putting nil or emtpy collection in a collection is
a recipe to disaster. All clients will have to check and you can avoid
that simply.
Put an empty collection.
This is not because some people may not know how to program in other
languages that we should copy that.
Stef
Le 5/1/15 14:01, Sebastian Sastre a écrit :
On Jan 5, 2015, at 10:38 AM, p...@highoctane.be
<mailto:p...@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:* ?
Phil
On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tu...@tudorgirba.com
<mailto:tu...@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
<sebast...@flowingconcept.com
<mailto:sebast...@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 <steph...@free.fr
<mailto:steph...@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 <http://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:p...@highoctane.be <mailto:mail%3ap...@highoctane.be> | Web:
http://philippeback.eu <http://philippeback.eu/>
Blog: http://philippeback.be <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 <http://spamcast.libsyn.com/>
Sparx Systems Enterprise Architect and Ability Engineering EADocX
Value Added Reseller
