January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Henrik Johansen

> On 05 Jan 2015, at 12:06 , Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > but not putting it on Object would change the feature since you do want it returning self on that case. No. In that case, you want to use ifNil: , not ifNilOrEmpty:. The only thing Object >> ifNilOrEmpty would support, is putting both collections and non-collection in the same variable, which is usually a bad idea to begin with, since it will lead to "are you a collection or single instance?" checks in almost every user of said variable. Cheers, Henry

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by Tudor Girba

Hi Sebastian, I really do not see how your reply applies to the case at hand. If you have a concrete remark regarding how something is less useful now, please feel free to make it. Cheers, Doru On Mon, Jan 5, 2015 at 3:00 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > +1 > > Remember that âoldâ also means that it *stands the test of time* > > We need to be careful while innovating with the basics (workspace, > inspecting, navigating code and debugging) because that impacts the whole > economy of using this technology. > > Make productivity go up, never down! > > One additional click doesnât sound like a lot but if that happens for > something that you do 400 times a day is ~8000 times a month or ~60 minutes > of clicking like crazy with overhead you didnât have before. > > UX is King. > > No way back from that, it really rules (the only thing we have in control > is what kingdom will we invent for it to rule) > > > > > On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr> wrote: > > + 10000 > > Debugging the rendering loops of Athens was such an example. In Bloc I get > some race conditions with MC forked process... another fun one. > Let people decide!!! > > Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! > I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list > is huge. > > > Stef > > Doru, > > I think your intention is a good one but slightly misplaced. I really > like the idea of GTInspector. It surely is a great tool and maybe I'll > start to build my own inspector on my kind of things. > To me the difference is between "motivated to do" or "forced to do". Most > of the time we are trying hard to solve our own problems. If in that > progress other problems are forced upon us we get easily distracted and > frustrated. The same goes for new tools. If I'm forced to use these it just > means I have to deal with it first and only then I'm allowed to deal with > my own problem. As it was in that special case the bug in nautilus and the > new inspector made me shy away from developing something in 4.0 and now I'm > back on 3.0. > > So I think the only possibility is to "offer" a new way of doing things > and give people time to adjust. > > Norbert > > Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > I think there must be a misunderstanding. > > There can be a good reason for having a basic inspector around, but I > think the reason is not because people cannot choose what to use. > > There is a toggle to enable/disable the GTInspector. But, even without > it, the main feature of the GTInspector is exactly to be extended the way > people want and not impose a fixed way. This is completely different from > what existed before. In fact, half a year ago there was no problem that > people could neither choose nor extend anything. In the meantime, we can > extend our workflows significantly. Adding the various flavors of browsing > objects is perhaps a couple of lines long and each of us can tweak it > because there is no higher entity that should decide anymore. > > What I cannot quite grasp is that while we pride ourselves with working > on a reflective language, when we have reflective tools, we seem to not be > able to take half an hour to build the tool that fits our needs. I am > still wondering what is needed to improve this. I think that it's a problem > of exercise or of communication, but it seems that just providing the > examples that I linked before is not enough and most people look at the > inspector still as a black box tool. I will try to work on a tutorial to > see if it gets better, but do you find the moldability proposition not > valuable or just unclear? > > But, as I said, there can still be a valid reason to enable a basic > inspector that relies on a minimal of libraries (so, definitely not the > Spec one) for the same reason we have an emergency debugger. > > Cheers, > Doru > > > On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr> wrote: > >> I will add basicInspect in Object so that we can get access to the old >> inspector. >> I like that people can choose their tools! >> I mentioned that 20 times but people do not care apparently. >> >> Stef >> >> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >> >> Is there a way to get the old tools via shortcut? >>> >>> I started something new with pharo 4.0 today. I discovered a bug in >>> Nautilus where every rename or deletion of a method raises a debugger. I >>> tried finding the bug but struggled because to me the new inspector is >>> really confusing. If I "just" want to unfold a few levels of references to >>> get a glimpse of the structure the new tool prevents me from doing that. >>> There is just to much information in this window and too much happening to >>> me. >>> To me it looks like a power tool you need to get used to. So it is >>> probably not the best tool for simple tasks and people new to this >>> environment might be overwhelmed. At least I would like to be able to use >>> the old tools. >>> >>> Norbert >>> >>> >>> >>> >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Esteban A. Maringolo

El Mon Jan 05 2015 at 10:50:48 AM, phil(a)highoctane.be <phil(a)highoctane.be> escribiÃ³: > Why not put that into a Trait? > > TDefaultValueIdiom>>ifEmptyOrNil: aDefaultObject > > So, if wanted,, one can put "uses TDefaultValueIdiom" (I am at a loss for > a great name here, help!) and do as Sebastian proposes. > > This will prevent pollution of Object while at the same time being able to > have the idiom available (and maybe with more than one form). > > But you can't "hot plug" a Trait to Object to have this behavior system-wide. Adding a trait involves recompilation AFAIR. The only thing I'd argue against is the naming. Otherwise is a very convenient method, when you go outside of the Smalltalk island and interact with API's not very well crafted or desgned to err on the "safe" side (empty collections instead o null), asking whether an object isNull or empty in the same method is really convenient. If we get purists, nil shouldn't exist either [1] and they should be replaced by domain specific abstractions representing the void/undefined. But we know there is a use case for nil, as IMO, there is a use case for isEmptyOrNil. However, whether you add it to Object in Pharo core image or not isn't really relevant, whoever wants/needs it can add it afterwards. Regards, [1] http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mista…

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Norbert Hartl

> Am 05.01.2015 um 14:43 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > > one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. > > Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. > > About #thing being meaningless, sure, Iâve mentioned as general example. I donât see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) > My point is that as long as you do not promise a certain type of object you will have to deal with the uncertainty what methods you can call on that object of uncertain type. By not using a check you just extend the life of this uncertainty a while longer (bad if the user of your code has to deal with it). Some has to deal with it if the object has to do something. And the earlier this uncertainty is removed the better it is. At least in my opinion. Norbert > Thanks for giving it a thought > > > > >> On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >>> >>> Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>>: >>> >>> >>>> On Jan 5, 2015, at 10:38 AM, phil(a)highoctane.be <mailto: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: ? >>> >> What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. >> It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. >> Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. >> Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. >> >> my 2 cents, >> >> norbert >> >>>> >>>> >>>> Phil >>>> >>>> >>>> >>>> On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto: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(a)flowingconcept.com <mailto: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(a)free.fr <mailto: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 <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:phil@highoctane.be <mailto:Mail%3Aphil@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 <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 >

Jan. 5, 2015

Re: [Pharo-dev] Old inspector and explorer

by Sebastian Sastre

+1 Remember that âoldâ also means that it stands the test of time We need to be careful while innovating with the basics (workspace, inspecting, navigating code and debugging) because that impacts the whole economy of using this technology. Make productivity go up, never down! One additional click doesnât sound like a lot but if that happens for something that you do 400 times a day is ~8000 times a month or ~60 minutes of clicking like crazy with overhead you didnât have before. UX is King. No way back from that, it really rules (the only thing we have in control is what kingdom will we invent for it to rule) > On Dec 26, 2014, at 2:42 PM, stepharo <stepharo(a)free.fr> wrote: > > + 10000 > > Debugging the rendering loops of Athens was such an example. In Bloc I get some race conditions with MC forked process... another fun one. > Let people decide!!! > > Doru I DO NOT WANT TO LEARN WHAT I DO NOT WANT TO LEARN! > I WANT to DECIDE WHEN. I control my agenda and my own schedule and my list is huge. > > > Stef >> Doru, >> >> I think your intention is a good one but slightly misplaced. I really like the idea of GTInspector. It surely is a great tool and maybe I'll start to build my own inspector on my kind of things. >> To me the difference is between "motivated to do" or "forced to do". Most of the time we are trying hard to solve our own problems. If in that progress other problems are forced upon us we get easily distracted and frustrated. The same goes for new tools. If I'm forced to use these it just means I have to deal with it first and only then I'm allowed to deal with my own problem. As it was in that special case the bug in nautilus and the new inspector made me shy away from developing something in 4.0 and now I'm back on 3.0. >> >> So I think the only possibility is to "offer" a new way of doing things and give people time to adjust. >> >> Norbert >> >>> Am 26.12.2014 um 13:18 schrieb Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: >>> >>> Hi, >>> >>> I think there must be a misunderstanding. >>> >>> There can be a good reason for having a basic inspector around, but I think the reason is not because people cannot choose what to use. >>> >>> There is a toggle to enable/disable the GTInspector. But, even without it, the main feature of the GTInspector is exactly to be extended the way people want and not impose a fixed way. This is completely different from what existed before. In fact, half a year ago there was no problem that people could neither choose nor extend anything. In the meantime, we can extend our workflows significantly. Adding the various flavors of browsing objects is perhaps a couple of lines long and each of us can tweak it because there is no higher entity that should decide anymore. >>> >>> What I cannot quite grasp is that while we pride ourselves with working on a reflective language, when we have reflective tools, we seem to not be able to take half an hour to build the tool that fits our needs. I am still wondering what is needed to improve this. I think that it's a problem of exercise or of communication, but it seems that just providing the examples that I linked before is not enough and most people look at the inspector still as a black box tool. I will try to work on a tutorial to see if it gets better, but do you find the moldability proposition not valuable or just unclear? >>> >>> But, as I said, there can still be a valid reason to enable a basic inspector that relies on a minimal of libraries (so, definitely not the Spec one) for the same reason we have an emergency debugger. >>> >>> Cheers, >>> Doru >>> >>> >>> On Thu, Dec 25, 2014 at 11:43 AM, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> I will add basicInspect in Object so that we can get access to the old inspector. >>> I like that people can choose their tools! >>> I mentioned that 20 times but people do not care apparently. >>> >>> Stef >>> >>> Le 23/12/14 11:50, Norbert Hartl a Ã©crit : >>> >>> Is there a way to get the old tools via shortcut? >>> >>> I started something new with pharo 4.0 today. I discovered a bug in Nautilus where every rename or deletion of a method raises a debugger. I tried finding the bug but struggled because to me the new inspector is really confusing. If I "just" want to unfold a few levels of references to get a glimpse of the structure the new tool prevents me from doing that. There is just to much information in this window and too much happening to me. >>> To me it looks like a power tool you need to get used to. So it is probably not the best tool for simple tasks and people new to this environment might be overwhelmed. At least I would like to be able to use the old tools. >>> >>> Norbert >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >> >

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by phil＠highoctane.be

Why not put that into a Trait? TDefaultValueIdiom>>ifEmptyOrNil: aDefaultObject So, if wanted,, one can put "uses TDefaultValueIdiom" (I am at a loss for a great name here, help!) and do as Sebastian proposes. This will prevent pollution of Object while at the same time being able to have the idiom available (and maybe with more than one form). Phil On Mon, Jan 5, 2015 at 2:43 PM, Sebastian Sastre < sebastian(a)flowingconcept.com> wrote: > one hugely typical case is having the model of an input that has either > nil because is pristine or an empty string and the app needs to guarantee > some default value that should *not be nil or an empty string*. > > Another frequent case is the response of some API that will typically > answer nil or an empty collection when something is not found and you want > to guarantee some value or model that should *not* be nil or an empty > collection. > > About #thing being meaningless, sure, Iâve mentioned as general example. I > donât see that every user of #thing *has* to use the ifNilOrEmpty:, only > those who care about guaranteeing that closure valued *if* none is found > which is expressed in the completely sensible form of receiving nil or an > empty collection :) > > Thanks for giving it a thought > > > > > On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 05.01.2015 um 14:01 schrieb Sebastian Sastre < > sebastian(a)flowingconcept.com>: > > > On Jan 5, 2015, at 10:38 AM, phil(a)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:* ? > > What is #thing supposed to do? This whole problem looks like a typical > javascript problem. You do anything and return anything and as all types > are auto-coerced into their target type all expressions look like the same > while meaning different things. > It looks problematic to me to treat nil and empty collection the same. > This might make sense in some business logic but not in general. In that > move a method is added to Object using methods it cannot know of like > #isEmpty. Object is no way more tied to Collection than it should be. > Another problem is that #thing does return anything but nothing > meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This > is probably something that needs to go into the class the implements > #thing. Everything else is far from being an interface. > Probably the solution to this is that #thing should return a concrete type > object that can be used with its defined interface. So if having an > one-liner is the ultimate goal one might need see the harm it produced on > the way. > > my 2 cents, > > norbert > > > > > Phil > > > > On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor(a)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(a)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(a)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" >> > > > > -- > --- > Philippe Back > Visible Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | 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 > > >

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by phil＠highoctane.be

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(a)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(a)flowingconcept.com> wrote: > >> >> On Jan 5, 2015, at 10:38 AM, phil(a)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(a)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(a)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(a)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" >>> >> >> >> >> >> >> >

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Sebastian Sastre

one hugely typical case is having the model of an input that has either nil because is pristine or an empty string and the app needs to guarantee some default value that should not be nil or an empty string. Another frequent case is the response of some API that will typically answer nil or an empty collection when something is not found and you want to guarantee some value or model that should not be nil or an empty collection. About #thing being meaningless, sure, Iâve mentioned as general example. I donât see that every user of #thing has to use the ifNilOrEmpty:, only those who care about guaranteeing that closure valued if none is found which is expressed in the completely sensible form of receiving nil or an empty collection :) Thanks for giving it a thought > On Jan 5, 2015, at 11:14 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>>: >> >> >>> On Jan 5, 2015, at 10:38 AM, phil(a)highoctane.be <mailto: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: ? >> > What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. > It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. > Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. > Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. > > my 2 cents, > > norbert > >>> >>> >>> Phil >>> >>> >>> >>> On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto: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(a)flowingconcept.com <mailto: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(a)free.fr <mailto: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 <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:phil@highoctane.be <mailto:Mail%3Aphil@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 <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

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by Norbert Hartl

> Am 05.01.2015 um 14:01 schrieb Sebastian Sastre <sebastian(a)flowingconcept.com>: > > >> On Jan 5, 2015, at 10:38 AM, phil(a)highoctane.be <mailto: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: ? > What is #thing supposed to do? This whole problem looks like a typical javascript problem. You do anything and return anything and as all types are auto-coerced into their target type all expressions look like the same while meaning different things. It looks problematic to me to treat nil and empty collection the same. This might make sense in some business logic but not in general. In that move a method is added to Object using methods it cannot know of like #isEmpty. Object is no way more tied to Collection than it should be. Another problem is that #thing does return anything but nothing meaningful. So every user of #thing has to use the #ifNilOrEmpty: foo. This is probably something that needs to go into the class the implements #thing. Everything else is far from being an interface. Probably the solution to this is that #thing should return a concrete type object that can be used with its defined interface. So if having an one-liner is the ultimate goal one might need see the harm it produced on the way. my 2 cents, norbert >> >> >> Phil >> >> >> >> On Mon, Jan 5, 2015 at 1:19 PM, Tudor Girba <tudor(a)tudorgirba.com <mailto: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(a)flowingconcept.com <mailto: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(a)free.fr <mailto: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 <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:phil@highoctane.be <mailto:Mail%3Aphil@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 <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 >> >> >

Jan. 5, 2015

Re: [Pharo-dev] Object>>ifNilOrEmpty: aBlock

by kilon alios

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(a)flowingconcept.com> wrote: > > On Jan 5, 2015, at 10:38 AM, phil(a)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(a)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(a)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(a)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" >> > > > > -- > --- > Philippe Back > Visible Performance Improvements > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 > Mail:phil@highoctane.be | 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 > > > >

Jan. 5, 2015