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

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

by Sebastian Sastre

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 <stepharo(a)free.fr> 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, 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: ? >> >>> >>> >>> 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 stepharo

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, 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:* ? > >> >> >> 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 >> >> 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 <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 2:56 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Of course, you can still do nonsense like > stuff := aCollection ifNilOrEmpty: [42] > but at least *that* problem is easier to pinpoint when later, a debugger with a user of stuff that expected it to be a collection pops up. > If the origin of stuff as a single instance is lost to the mists of time (say, Object implements ifNilOrEmpty: and someone called stuff: with an Object without error), it's easier to end up with a solution of "fixing" the use to > (stuff isKindOf: Collection) "or is that isCollection?" > ifTrue: ["Code handling each entry"] > ifFalse: ["Code handling single instance"] > > And now there's two stinks. > > Cheers, > Henry Ah, right. I get your point now. I'd see that as an abuse. Iâve mentioned a couple of examples before, the âgoodâ uses of this convenience are meant for handling the empty string or nil frequent case and APIs that are more functionally inspired (like when they use an Option / Some / None / Nothing as response and you need to normalize that into smalltalk style)

Jan. 5, 2015

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

by stepharo

> taste is taste but would you care to illustrate your point with examples? > Iâm curious about it Henry did it well.

Jan. 5, 2015

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

by stepharo

>> Hi Henry, >> >> I think you are talking of a different feature or maybe promoting >> that things should not be treated as possibly nil or empty >> collections which is understandable but Iâm treating the programers >> as good citizens that know what they do and bear the consequences >> (not as beasts that should be educated or indoctrinated or prevented >> on how to use code and do things) > > No, I'm talking about exactly what I quoted, implementing > ifNilOrEmpty: on just UndefinedObject/Collection, but not Object. > Doing that is not about indoctrinating, but preventing bad code > resulting from using the same variable to hold non-polymorphic objects. I thought the same :) Thanks Henry I love your view on the world.

Jan. 5, 2015

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

by stepharo

>> >> 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. + 100. > > Cheers, > Henry

Jan. 5, 2015

Re: [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost

by Blondeau Vincent

Hi, Happy new year too! I succeeded to have a working example. I wrote the code but I can't commit it. Can you add me on the project please? Just to give some indications for the code I changed. Globally the primitive call is good. But when you pass 'nil' as argument for the primitive, it will not be converted to 'null' ('null' have for value 0). To have the 0, either you change nil into 0 or you add the option #optCoerceNilToNull in the call (because it is not the default...) (See 'NBNativeCodeGen class>>defaultOptions' for the others). It is the mainly problem! Concerning the arguments allocation there is some tips: 'NativeBoost allocate: <number>' allocates a memory segment of the size given by <number> and return the address to it. But it is better to use 'NativeBoost allocate: (NBExternalType sizeOf: 'ulong')' or 'NativeBoost allocate: (NBExternalType sizeOf: 'DWORD')' for both dwType and lSize arguments. With some advance, you will see in the example4 that the RegQueryValueExA doesn't return a valid error value... I don't know why... I hope it will be helpful, Cheers, Vincent -----Message d'origine----- De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de Torsten Bergmann EnvoyÃ© : dimanche 4 janvier 2015 21:43 Ã : Pharo Development List Objet : [Pharo-dev] Wrapping RegQueryValueExA in NativeBoost Hi, Happy new year! I try to wrap some API methods using NativeBoost to access Win32 Registry and broaden the Pharo support for Windows. Currently I'm already able to - create registry keys (RegCreateKeyA API) - open registry keys (RegOpenKeyExA API) - delete registry keys (RegDeleteKeyA API) - close registry key handles (RegCloseKey API) Now I additionally want to query some keys using the "RegQueryValueExA" API (http://msdn.microsoft.com/en-us/library/windows/desktop/ms724911%28v=vs.85%…) As I tried an example in an elder Smalltalk/MT first (see attached) I know it is working from the Win32 API side. My NativeBoost definition in Pharo for wrapping the function looks like this (similar to MSDN): regQueryValueExA: hKey with: lpValueName with: lpReserved with: lpType with: lpData with: lpcbData <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCall: #(LONG RegQueryValueExA( HKEY hKey, LPCTSTR lpValueName, LPDWORD lpReserved, LPDWORD lpType, LPBYTE lpData, LPDWORD lpcbData)) module: #advapi32 But when I call it I get a "Generic error" thrown by NB and independent how hard I try I can not get this call to work in NativeBoost. I checked all arguments, checked the type definitions (pool WinTypes which is similar to NBWinTypes), played with options, ... but was not able to find out what I'm doing wrong in Pharo. Meanwhile after investing several days of my spare time it looks like I cant "see the wood because of all the trees". I would really appreciate if someone with enough knowledge of NativeBoost could have a second look to point my into the right direction. To reproduce: ============= - use a fresh Pharo4.0 Latest update: #40428 - open World menu -> Configuration Browser and load "OSWindows" project - go to class WinRegistry - there is the NativeBoost API definition in method #regQueryValueExA:with:with:with:with:with: - and a method #example2 that calls this in a similar way as in my Smalltalk/MT example (if you try this example you get the "Generic error") Many thanks in advance! Bye T. Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Jan. 5, 2015

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

by Henrik Johansen

> On 05 Jan 2015, at 5:37 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 05 Jan 2015, at 5:07 , Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >> >> >>> On Jan 5, 2015, at 1:48 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >>> >>>> >>>> On 05 Jan 2015, at 4:20 , Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >>>> >>>> Ah Henry but you are making the code to know if itâs a collection or not, I talking about making the code specifically to ignore that. >>>> >>>> Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives? >>>> >>> >>> I did that already: >> >> I took a look at the thread and I donât see examples of bad code >> >> Iâm still curious about what you mean by that >> > > Are you joking? > I quoted the elaboration on what I mean by bad code... > > Cheers, > Henry Just in case there's something weird with your mail client, it was: "it will lead to "are you a collection or single instance?" checks in almost every user of said variable." Which is unneccessary pain compared to using a collection with a single entry if that's what you mean instead, and have all users expect a collection of items to deal with. So you'd do: stuff: aCollection stuff := aCollection ifNilOrEmpty: ["Default collection" #(1 2 3)] which will raise an error if you pass in, say, Object new as pishPosh, instead of leaving each user of stuff to determine whether stuff is a collection, an object, or nil. Of course, you can still do nonsense like stuff := aCollection ifNilOrEmpty: [42] but at least *that* problem is easier to pinpoint when later, a debugger with a user of stuff that expected it to be a collection pops up. If the origin of stuff as a single instance is lost to the mists of time (say, Object implements ifNilOrEmpty: and someone called stuff: with an Object without error), it's easier to end up with a solution of "fixing" the use to (stuff isKindOf: Collection) "or is that isCollection?" ifTrue: ["Code handling each entry"] ifFalse: ["Code handling single instance"] And now there's two stinks. Cheers, Henry

Jan. 5, 2015

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

by Henrik Johansen

> On 05 Jan 2015, at 5:07 , Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > >> On Jan 5, 2015, at 1:48 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >>> >>> On 05 Jan 2015, at 4:20 , Sebastian Sastre <sebastian(a)flowingconcept.com <mailto:sebastian@flowingconcept.com>> wrote: >>> >>> Ah Henry but you are making the code to know if itâs a collection or not, I talking about making the code specifically to ignore that. >>> >>> Why that would lead to "bad code"? can you elaborate or put examples instead of adjectives? >>> >> >> I did that already: > > I took a look at the thread and I donât see examples of bad code > > Iâm still curious about what you mean by that > Are you joking? I quoted the elaboration on what I mean by bad code... Cheers, Henry

Jan. 5, 2015

Re: [Pharo-dev] Essay Topics

by horrido

Oh, I forgot to mention. Please notify me of your topic choice at my personal email: horrido.hobbies at gmail dot com. That way, I can coordinate the essay activities. Thanks. -- View this message in context: http://forum.world.st/Essay-Topics-tp4797847p4797876.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 5, 2015