On Mon, Jan 5, 2015 at 2: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:* ? > I'd agree to that for the use case you mention. Implementing it as Eliot recommends looks like the way to go. Phil > > > > 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" >> > > > > -- > --- > Philippe Back > Visible Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:[email protected] | 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 > > > > -- --- Philippe Back Visible Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:[email protected] | 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
