March 2022 - Pharo-users - lists.pharo.org

Re: BlockClosure folding

by Richard O'Keefe

The motivating example can be written aHasDot := a includes: $.. bHasDot := b includes: $.. ^aHasDot = bHasDot ifFalse: [bHasDot] ifTrue: [aHasDot ifTrue: [a < b] ifFalse: [a > b]] (Dijkstra was right. People *do* forget that '=' is one of the standard Boolean operations, and it matters.) This is absolutely straightforward, and without wasting any time wondering what the three-headed IF monster is, we can go straight to the big puzzle: "I can see at a glance what this DOES, but what the heck does it MEAN?" When would this be useful? What would be a good name for this combination, however expressed? I think the moral here is "when you have code whose structure is so complex that you are tempted to construct special control flow objects to make it LOOK simpler, rewrite it so that it IS simpler." I once wrote a class called Distributor based on Boost 'signal's. It was an interesting exercise, and I am still finding mistakes in it. It was not entirely unlike ComplexCondition. What I *haven't* done in the 10 years since I wrote it is found any use for it. On Wed, 16 Mar 2022 at 07:15, <sean(a)clipperadams.com> wrote: > ComplexCondition as described in Andres Valloud, "A Mentoring Course on > Smalltalk" > <http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/37888…> > is available at http://www.squeaksource.com/ComplexCondition.html > > With it, you can do something like: > > ^[a includes: $.], [b includes: $.] > ifAllTrue: [a < b] > ifAnyTrue: [b includes: $.] > otherwise: [a > b] > >

March 16, 2022

Re: BlockClosure folding

by HernÃ¡n Morales Durand

This is an interesting pattern. Thank you for sharing. HernÃ¡n El mar, 15 mar 2022 a las 4:43, JuliÃ¡n Maestri (<serpi90(a)gmail.com>) escribiÃ³: > Not satisfying the equality, but you can use polymorphism. > > Block >> , aBlock > ^ BlockCompositor andAll: OrderedCollection with: self with: aBlock > > BlockCompositor >> #, aBlock > conditions add: aBlock. > > BlockCompositor >> value: anObject > ^ conditions allSatisfy: [:e | e value: anObject ] > > I don't really like the name BlockCompositor, but can't think of a better > name at the moment. > > You could also implement logic for #or: using #+ and: #anySatisfy: for > example, but need to safeguard against mixing both conditions. > > On Mon, 14 Mar 2022 at 22:29, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> I think I saw a coding pattern a while ago that allows you to do the >> following: >> >> cond1 , cond2 , cond3 , cond4 >> >> And providing a kind of folding selector condition #and: you would get: >> >> [ cond1 and: [ cond2 and: [ cond3 and: [ cond4 ] ] ] ]. >> >> for example: >> >> conditions := [ : each | each firstName = 'Boca' ] , >> [ : each | each lastName = 'Baret' ] , >> [ : each | each fullName = 'Virgasia' ]. >> >> such that the following assert is met: >> >> self assert: conditions equals: [ : each | each firstName = 'Boca' and: [ >> each lastName = 'Baret' and: [ each fullName = 'Virgasia' ] ] ]. >> >> Any ideas or pointers? >> >> Cheers, >> >> HernÃ¡n >> >>

March 16, 2022

Re: BlockClosure folding

by HernÃ¡n Morales Durand

Exactly. This was what I was looking for. Thank you Sean. HernÃ¡n El mar, 15 mar 2022 a las 19:15, <sean(a)clipperadams.com> escribiÃ³: > ComplexCondition as described in Andres Valloud, "A Mentoring Course on > Smalltalk" > <http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/37888…> > is available at http://www.squeaksource.com/ComplexCondition.html > > With it, you can do something like: > > ^[a includes: $.], [b includes: $.] > ifAllTrue: [a < b] > ifAnyTrue: [b includes: $.] > otherwise: [a > b] > >

March 16, 2022

Re: Null Object Pattern

by Todd Blanchard

Why do you not just do something like [ âcomplicated code that might fail somewhere in hereâ ] on: Error do: [:error | nil] Use the on:do: exception handling to stay safe. Result := [anObject long chain of messages that might return a nilValue ] on: Error do: [:e | nil]. > On Mar 15, 2022, at 11:16 AM, sean(a)clipperadams.com wrote: > > I had some chaining that was getting too complex due to many nil checks, so I started to refactor using a Null Object. > > However, Iâm struggling a bit with the refactor due to inlining. Since #ifNil: variants might be inlined, it seems that something like: > > anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] > > must be changed into something like: > > anObject with a long chain of messages isNil ifFalse: [ anObject with a long chain of messages ââ¦â ]. > > Obviously, I can use a temp to have: > > result := anObject with a long chain of messages. > > result isNil ifFalse: [ result ââ¦â ]. > > But both seem ugly and make me question using this pattern. > > What am I missing? > > After 40+ years of Mooreâs Law, can we turn off these inlines by default? >

March 16, 2022

Re: Null Object Pattern

by Bernardo Ezequiel Contreras

if you are using the null object pattern then you should not write those checks (ifNil:ifNotNil:, isNil, isNotNil). you should send the message to an instance of the null object and that object should decide what to do. just an opinion. On Tue, Mar 15, 2022 at 3:16 PM <sean(a)clipperadams.com> wrote: > I had some chaining that was getting too complex due to many nil checks, > so I started to refactor using a Null Object. > > However, Iâm struggling a bit with the refactor due to inlining. Since > #ifNil: variants might be inlined, it seems that something like: > > anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] > > must be changed into something like: > > anObject with a long chain of messages isNil ifFalse: [ anObject with a > long chain of messages ââ¦â ]. > > Obviously, I can use a temp to have: > > result := anObject with a long chain of messages. > > result isNil ifFalse: [ result ââ¦â ]. > > But both seem ugly and make me question using this pattern. > > 1. > > What am I missing? > 2. > > After 40+ years of Mooreâs Law, can we turn off these inlines by > default? > > -- Bernardo E.C. Sent from a cheap desktop computer in South America.

March 16, 2022

Re: Null Object Pattern

by Richard O'Keefe

I have a bad feeling about this. To start with, why do you CARE whether a particular method is inlined or not? <quote> However, Iâm struggling a bit with the refactor due to inlining. Since #ifNil: variants might be inlined, it seems that something like: anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] must be changed into something like: anObject with a long chain of messages isNil ifFalse: [ anObject with a long chain of messages ââ¦â ]. </quote> This makes absolutely no sense to me. What makes you think that the combination "_ isNil ifFalse: [_]" will NOT be inlined? In Squeak, x ifNotNil: [...] turns into x; nil; ==; jumpFalse and x isNil ifFalse: [...] turns into x; send isNil; jumpFalse where "send isNil" is a single byte. I don't see a substantial difference here. (I'd have checked in Pharo, but after many interface changes I no longer know how to do view|bytecode.) The thing that rings loud alarm bells for me is there being "long chains" in the first place. Can you give an example? In my own programming, I've generally found that nils turning up in the middle of a chain indicates a serious design error somewhere. On Wed, 16 Mar 2022 at 07:16, <sean(a)clipperadams.com> wrote: > I had some chaining that was getting too complex due to many nil checks, > so I started to refactor using a Null Object. > > However, Iâm struggling a bit with the refactor due to inlining. Since > #ifNil: variants might be inlined, it seems that something like: > > anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] > > must be changed into something like: > > anObject with a long chain of messages isNil ifFalse: [ anObject with a > long chain of messages ââ¦â ]. > > Obviously, I can use a temp to have: > > result := anObject with a long chain of messages. > > result isNil ifFalse: [ result ââ¦â ]. > > But both seem ugly and make me question using this pattern. > > 1. > > What am I missing? > 2. > > After 40+ years of Mooreâs Law, can we turn off these inlines by > default? > >

March 16, 2022

Re: Null Object Pattern

by Esteban Maringolo

+1 Inlining breaks the fundamental piece of OOP: Message sends. I'm sure there are use cases where inlining adds a significant speedup, but for some messages, I prefer them to be sent. Regards! Esteban A. Maringolo On Tue, Mar 15, 2022 at 3:16 PM <sean(a)clipperadams.com> wrote: > > I had some chaining that was getting too complex due to many nil checks, so I started to refactor using a Null Object. > > However, Iâm struggling a bit with the refactor due to inlining. Since #ifNil: variants might be inlined, it seems that something like: > > anObject with a long chain of messages ifNotNil: [ :result | ââ¦â ] > > must be changed into something like: > > anObject with a long chain of messages isNil ifFalse: [ anObject with a long chain of messages ââ¦â ]. > > Obviously, I can use a temp to have: > > result := anObject with a long chain of messages. > > result isNil ifFalse: [ result ââ¦â ]. > > But both seem ugly and make me question using this pattern. > > What am I missing? > > After 40+ years of Mooreâs Law, can we turn off these inlines by default?

March 15, 2022

Null Object Pattern

by sean＠clipperadams.com

I had some chaining that was getting too complex due to many nil checks, so I started to refactor using a Null Object. However, Iâm struggling a bit with the refactor due to inlining. Since #ifNil: variants might be inlined, it seems that something like: anObject with a long chain of messages ifNotNil: \[ :result | ââ¦â \] must be changed into something like: anObject with a long chain of messages isNil ifFalse: \[ anObject with a long chain of messages ââ¦â \]. Obviously, I can use a temp to have: result := anObject with a long chain of messages. result isNil ifFalse: \[ result ââ¦â \]. But both seem ugly and make me question using this pattern. 1. What am I missing? 2. After 40+ years of Mooreâs Law, can we turn off these inlines by default?

March 15, 2022

Re: BlockClosure folding

by sean＠clipperadams.com

ComplexCondition as described in [Andres Valloud, "A Mentoring Course on Smalltalk"](http://www.lulu.com/product/paperback/a-mentoring-course-on-smalltalk/3788890) is available at http://www.squeaksource.com/ComplexCondition.html With it, you can do something like: ``` ^[a includes: $.], [b includes: $.] ifAllTrue: [a < b] ifAnyTrue: [b includes: $.] otherwise: [a > b] ```

March 15, 2022

Re: BlockClosure folding

by JuliÃ¡n Maestri

Not satisfying the equality, but you can use polymorphism. Block >> , aBlock ^ BlockCompositor andAll: OrderedCollection with: self with: aBlock BlockCompositor >> #, aBlock conditions add: aBlock. BlockCompositor >> value: anObject ^ conditions allSatisfy: [:e | e value: anObject ] I don't really like the name BlockCompositor, but can't think of a better name at the moment. You could also implement logic for #or: using #+ and: #anySatisfy: for example, but need to safeguard against mixing both conditions. On Mon, 14 Mar 2022 at 22:29, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > I think I saw a coding pattern a while ago that allows you to do the > following: > > cond1 , cond2 , cond3 , cond4 > > And providing a kind of folding selector condition #and: you would get: > > [ cond1 and: [ cond2 and: [ cond3 and: [ cond4 ] ] ] ]. > > for example: > > conditions := [ : each | each firstName = 'Boca' ] , > [ : each | each lastName = 'Baret' ] , > [ : each | each fullName = 'Virgasia' ]. > > such that the following assert is met: > > self assert: conditions equals: [ : each | each firstName = 'Boca' and: [ > each lastName = 'Baret' and: [ each fullName = 'Virgasia' ] ] ]. > > Any ideas or pointers? > > Cheers, > > HernÃ¡n > >

March 15, 2022