Cocoa mail archive
Re: Why is [nil aMessage] a no-op?
FROM : Scott Ribe
DATE : Fri Apr 18 16:49:22 2008
> Here's a simple example:
>
> - (void) dealloc
> {
> [someIvar release];
> [super dealloc];
> }
It's worth noting that even in C++ there's a special case for delete, so
that one can write "delete myptr" rather than "if(myptr) delete myptr)" 10
bazillion[1] times. I was around when this behavior was standardized, and
there were people arguing strenuously that this would support "sloppy
programming", whereas my opinion is that writing redundant code
unnecessarily is what is sloppy.
> 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.
Here's an example from my own use. Imagine a "workflow" type application.
You'd have some kind of big chunk of structured data (probably backed by
database, but that's irrelevant here). At various stages in the process, you
would show different subsets of the details to different users, using
different forms from different nibs.
Approach 1: different window controller for each form. Lots of common code
for handling controls is duplicated between forms.
Approach 2: extract code for common controls into a base class. Each form
has its window controller that inherits from the base class and implements
the non-common controls. There is the possibility that either some forms
still have duplicated code, or that to eliminate duplicated code requires
more than one level of inheritance (yuck!). But the biggest problem is that
as requirements change, some controls may change from being common or not,
and the code may have to be moved around in the hierarchy.
Approach 3: put code for all controls in the base class, and count on the
fact that controls that don't exist in a nib will have their outlets set to
nil, and messages to them will be noops. There *may* still be some cases
where you will need to know if a control actually exists, but in most cases
you simply don't need to know. (Bindings change the balance, because they
eliminate a lot of code that interacts with controls.)
[1] Yeah, yeah, yeah. Templates, Boost, Loki: modern C++ code should have
far fewer explicit invocations of delete than what we were writing back in
the '80s.
--
Scott Ribe
<email_removed>
http://www.killerbytes.com/
(303) 722-0567 voice
DATE : Fri Apr 18 16:49:22 2008
> Here's a simple example:
>
> - (void) dealloc
> {
> [someIvar release];
> [super dealloc];
> }
It's worth noting that even in C++ there's a special case for delete, so
that one can write "delete myptr" rather than "if(myptr) delete myptr)" 10
bazillion[1] times. I was around when this behavior was standardized, and
there were people arguing strenuously that this would support "sloppy
programming", whereas my opinion is that writing redundant code
unnecessarily is what is sloppy.
> 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.
Here's an example from my own use. Imagine a "workflow" type application.
You'd have some kind of big chunk of structured data (probably backed by
database, but that's irrelevant here). At various stages in the process, you
would show different subsets of the details to different users, using
different forms from different nibs.
Approach 1: different window controller for each form. Lots of common code
for handling controls is duplicated between forms.
Approach 2: extract code for common controls into a base class. Each form
has its window controller that inherits from the base class and implements
the non-common controls. There is the possibility that either some forms
still have duplicated code, or that to eliminate duplicated code requires
more than one level of inheritance (yuck!). But the biggest problem is that
as requirements change, some controls may change from being common or not,
and the code may have to be moved around in the hierarchy.
Approach 3: put code for all controls in the base class, and count on the
fact that controls that don't exist in a nib will have their outlets set to
nil, and messages to them will be noops. There *may* still be some cases
where you will need to know if a control actually exists, but in most cases
you simply don't need to know. (Bindings change the balance, because they
eliminate a lot of code that interacts with controls.)
[1] Yeah, yeah, yeah. Templates, Boost, Loki: modern C++ code should have
far fewer explicit invocations of delete than what we were writing back in
the '80s.
--
Scott Ribe
<email_removed>
http://www.killerbytes.com/
(303) 722-0567 voice
