it's impossible to talk about a project that i don't understand. this sentence *In the second code especially, the problem is that `position` could be many types that are not in the same hierarchy,*
draw my attention, because i did many hierarchies when you don't need to do it. just use polymorphic messages, objects that have the same protocol. In that case they don't need to be in the same hierarchy. HTH. On Wed, Mar 16, 2022 at 4:42 PM <s...@clipperadams.com> wrote: > 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. > -- Bernardo E.C. Sent from a cheap desktop computer in South America.
