Re: Why is [nil aMessage] a no-op?

FROM : Rob Napier
DATE : Fri Apr 18 18:19:17 2008

On Apr 18, 2008, at 9:56 AM, Adam P Jenkins wrote:
>
> On Apr 18, 2008, at 1:16 AM, Graham Cox wrote:

>>
>> Here's a simple example:
>>
>> - (void) dealloc
>> {
>>  [someIvar release];
>>  [super dealloc];
>> }
>>
>> is <someIvar> really initialised? Maybe it's nil? Do I care at this 
>> point? no - either way, the code is correct - if the object was 
>> made, it's released, if it wasn't, it's a no-op. Exactly what you 
>> want.

>
> That makes a lot of sense.  I can now picture many lines of code 
> I've written over the years which wouldn't have been necessary with 
> this feature.
>
> Thanks a lot to everyone who responded to my question.  I now 
> understand the pros and cons of the nil-eats-messages feature much 
> better, and it doesn't seem like a mis-feature to me now.



In Martin Fowler's "Refactoring: Improving the Design of Existing 
Code", even as a Java-centric writer he discusses the utility of the 
Null Object (the strict-typing version of the nil-eats-message 
pattern). Some background he quotes from Ron Jeffries (of Extreme 
Programming fame):

---
   We first started using the null object pattern when Rich Garzaniti 
found that lots of code in the system would check objects for presence 
before sending a message to the object. We might ask an object for its 
person, then ask the result whether it was null. If the object was 
present, we would ask it for its rate. We were doing this in several 
places, and the resulting duplicate code was getting annoying.
   So we implemented a missing-person object that answered a zero rate 
(we call our null objects missing objects). Soon missing person knew a 
lot of methods, such as rate. Now we have more than 80 null-object 
classes.
...
   An interesting characteristic of using null objects is that things 
almost never blow up. Because the null object responds to all the same 
messages as a real one, the system generally behaves normally. This 
can sometimes make it difficult to detect or find a problem, because 
nothing ever breaks. Of course, as soon as you begin inspecting the 
objects, you'll find the null object somewhere where it shouldn't be.
---

Like ObjC memory management, nil-eats-message is something that new 
ObjC programmers rail against (I know I did), but that experienced 
ObjC programmers grow comfortable with and eventually quite fond of. 
It doesn't make it the one-and-only "right way," but it demonstrates 
that it's generally more useful than it is dangerous.

-Rob