[Pharo-users] Re: BlockClosure folding

[sean]

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]
```

[Pharo-users] Null Object Pattern

[sean]

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?

[Pharo-users] Re: Null Object Pattern

[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  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?

[Pharo-users] Re: Null Object Pattern

[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?


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 “…” ].


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,  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?
>
>

[Pharo-users] Re: Null Object Pattern

[Todd Blanchard via Pharo-users]

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, s...@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?
> 

[Pharo-users] Re: Null Object Pattern

[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  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.

[Pharo-users] Re: BlockClosure folding

[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,  escribió:

> ComplexCondition as described in Andres Valloud, "A Mentoring Course on
> Smalltalk"
> 
> 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]
>
>

[Pharo-users] Re: BlockClosure folding

[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 ()
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.mora...@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
>>
>>