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.

I agree as a general rule, but it can get complicated, especially when crossing library boundaries. Once one uses a null object, no one anywhere can use those messages. This might, for example, make experimentation, refactoring and porting harder.

At the risk of further distracting the conversation from the question of inlining, I was having lots of trouble applying the idea you mentioned to this (low level hack):

self transcriptable

ifNil: [

self notify: 'Transcript subject not found'

"We want this to be resumable because maybe e.g. the model just hasn't been loaded yet" ]

ifNotNil: [

"This is inside the guard because to get the line, we need a subject"

self line ifNil: [

"Brand new snippet"

self initializeLine.

^ self ] ].

And this:

self snippet line position ifNotNil: [ :position |

self firePlayerRequest: [ :player | player currentPosition: position ] ]

In the second code especially, the problem is that `position` could be many types that are not in the same hierarchy, so to send a message to the null object instead probably means further polluting Object for the non-null case.