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, <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. > > 1. > > What am I missing? > 2. > > After 40+ years of Moore’s Law, can we turn off these inlines by > default? > >
