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