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

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

by phil＠highoctane.be

On Mon, Jan 5, 2015 at 2: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:* ? > 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 <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 > > > > -- --- 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 Sebastian Sastre

> 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 <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] [Bulk] [Bulk] Can MongoTalk execute plan javascript MongoDB queries?

by Norbert Hartl

> Am 05.01.2015 um 04:59 schrieb Yanni Chiu <yanni(a)rogers.com>: > > > On Jan 4, 2015, at 4:38 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> someCollection select: { >> '$or' -> { >> { 'name' -> { >> '$regex' -> 'test' . >> '$options' -> 'i' } asDictionary } asDictionary. >> { 'description' -> { >> '$regex' -> 'test' . >> '$options' -> 'i' } asDictionary } asDictionary >> } >> } asDictionary > > That worked. I was close, but I was using $or: instead of $or, and I was missing one level of asDictionary. > > Just for the archive, thereâs one more query I needed, which was to find an object based on itâs object id. I ended up using: > > voyageId := Integer readFrom: (request at: #voyageId) base: 16. > someModel := SomeModel selectOne: { '_id' -> (OID value: voyageId) } asDictionary. > > This is a web app using Teapot and Mustache, so I write the voyageId out using: > > self voyageId value printStringHex Sounds cool. If you have anything to publish I'm interested what you've done. Especially if you have some nice tricks doing form handling in teapot. Btw. for the archive. A common use case I encounter is to query objects that are being referenced by another object. It works like this AnyClass>>#referencedBy: anObject ^ AnyClass selectMany: { 'reference.__id' -> anObject voyageId } asDictionary Norbert

Jan. 5, 2015

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

by Sebastian Sastre

> On Jan 5, 2015, at 10:19 AM, 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 ok, why?

Jan. 5, 2015

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

by phil＠highoctane.be

In business apps, the need for default values happen all the time, so the idiom has value (not sure for the message name though). We could use x := [ self thing ] ifError: [ someDefault ] 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? 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. 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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40429 Home: https://github.com/pharo-project/pharo-core

Jan. 5, 2015

[pharo-project/pharo-core] a28e71: 40429

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: a28e7177916f5db79ce3ca9b60d4bc0f5e7cad9c https://github.com/pharo-project/pharo-core/commit/a28e7177916f5db79ce3ca9b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-01-05 (Mon, 05 Jan 2015) Changed paths: M Kernel.package/Float.class/class/instance creation/fromIEEE32Bit_.st A KernelTests.package/FloatTest.class/instance/tests - IEEE 754/test32bitConversion.st A Morphic-Core.package/HandMorph.class/class/events-processing/cleanUp.st A Morphic-Core.package/HandMorph.class/class/events-processing/eventStats.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStatsStart.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStatsStop.st A Morphic-Core.package/HandMorph.class/class/events-processing/logEventStats_.st A Morphic-Core.package/HandMorph.class/class/settings/logEventStatsEnabled.st A Morphic-Core.package/HandMorph.class/class/settings/logEventStatsEnabled_.st A Morphic-Core.package/HandMorph.class/class/settings/settingsOn_.st M Morphic-Core.package/HandMorph.class/instance/events-processing/handleEvent_.st R Morphic-Core.package/HandMorph.class/instance/events-processing/logEventStats_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script429.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40429.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40429 14668 HandMorph event statistics should be off by default with preference https://pharo.fogbugz.com/f/cases/14668 14652 Float class fromIEEE32Bit: gradual underflow handling is buggy https://pharo.fogbugz.com/f/cases/14652 http://files.pharo.org/image/40/40429.zip

Jan. 5, 2015

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

by Tudor Girba

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

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 :) >> >> >> > >

Jan. 5, 2015

Re: [Pharo-dev] WhatsUp from: 2015-01-05 until: 2015-01-18

by phil＠highoctane.be

### Here's what I've been up to since the last WhatsUp Released a production version of the network software I've been working on. Got it installed on client premises and it works nicely (very solid server I have to say). Wrote a documentation book using Pillar for the system (worked well after a couple friction moments). Interviewed Herby on Amber Smalltalk Started a book on Amber using Pillar Tweeted some things with the #Pharo hashtag ### What's next, until 2015-01-18 (*): More interviews on Amber (whoever wants one done with Pharo people, just send me a note, I'd be happy to oblige). Prepare talk for FOSDEM Work on Amber Learn more on how to hook databases in Pharo Enter maintenance phase for commercial project before new features developed / support deployments. Phil

Jan. 5, 2015