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