Of course. If you know what you are doing you will not abuse it and it will not be a recipe for disaster.
You can also make recipes for disaster putting globals in Smalltalk, abusing #become: nesting ifTrue: etc etc etc which is stuff that is already there decades ago The shared convenience is for who feels it convenient. That usually happens when you have to deal with APIs which design that are out of your control and you use it to normalize it conveniently (AKA in a cheap one-liner hence this method) > On Jan 5, 2015, at 4:36 PM, stepharo <[email protected]> wrote: > > 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, [email protected] <mailto:[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] >>> <mailto:[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] <mailto:[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] >>> > <mailto:[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 <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:[email protected] <mailto:mail%[email protected]> | Web: >>> http://philippeback.eu <http://philippeback.eu/> >>> Blog: http://philippeback.be <http://philippeback.be/> | Twitter: >>> @philippeback >>> Youtube: http://www.youtube.com/user/philippeback/videos >>> <http://www.youtube.com/user/philippeback/videos> >>> >>> High Octane SPRL >>> rue cour Boisacq 101 | 1301 Bierges | Belgium >>> >>> Pharo Consortium Member - http://consortium.pharo.org/ >>> <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 >>> >>> >> >
