Exception handling is used a lot. Check senders of #on:do: 457 in my Pharo 3.0 That's not counting the 303 #ensure: that are used transparently in things like: aFileRef readStreamDo: [ :s | s upToEnd ] Phil On Mon, Jan 5, 2015 at 2:12 PM, kilon alios <kilon.alios@gmail.com> wrote:
I dont know javascript well nor pharo but I am coming from python and for this scenario it would make more sense to me to use an exception than an actual check. At least that is the way Python deals with this situation which is an approach I really like.
I know Pharo has exception handling as well, but unlike Python where exception handling is very popular I have barely seen it used by pharo coders. I am curious why .
On Mon, Jan 5, 2015 at 3:01 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:
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:* ?
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"