I see , very interesting I will definitely take a look because obviously this something I want to use too .
On Mon, Jan 5, 2015 at 3:44 PM, [email protected] <[email protected]> wrote: > 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 <[email protected]> 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 < >> [email protected]> wrote: >> >>> >>> On Jan 5, 2015, at 10:38 AM, [email protected] 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 <[email protected]> >>> 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 < >>>> [email protected]> 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 <[email protected]> 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" >>>> >>> >>> >>> >>> >>> >>> >> > > > > >
