Re: Why is [nil aMessage] a no-op?
Re: Why is [nil aMessage] a no-op?
- Subject: Re: Why is [nil aMessage] a no-op?
- From: Rob Napier <email@hidden>
- Date: Fri, 18 Apr 2008 12:19:17 -0400
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden