Re: Questions about memory management (was Re: I must be missing something... (Categories))

In article <xsCdnc8pEJZZbqXVnZ2dnUVZ_q7inZ2d@[EMAIL PROTECTED]
>,
 Don Bruder <dakidd@[EMAIL PROTECTED]
> wrote:

> In article <uce-A4F316.09013724052008@[EMAIL PROTECTED]
>,
>  Gregory Weston <uce@[EMAIL PROTECTED]
> wrote:
> 
> > > which is what I've been trying to 
> > > figure out all along. Up to now, I've been under the impression -
now 
> > > clearly wrong - that the super's init was the one that was being 
> > > invoked.
> > 
> > No. Super's init *is* the one that's being invoked because super is
the 
> > class for which alloc was invoked and is the class of the type alloc 
> > handed back.
> 
> AUGH!!!!!
> 
> I just thought I had it figured out, and now you're telling me I've 
> *STILL* got it backwards?!?!?
> 
> I think I'm gonna cry...
> 
> Or my head is gonna explode...
> 
> Or SOMETHING...
> 
> So which is it?!?!? I'm wrong when I think super's init runs.

No. You're right when you think super's init runs. That's not what you 
said in the previous post.

"I've been under the impression - now clearly wrong - that the super's 
init was the one that was being invoked."

I'm saying that impression isn't wrong.


Ah. And now I think *I* understand what you were doing. You were 
invoking alloc/init on the superclass, and then following up with an 
explicit invocation of the init method for the class you actually wanted.

Two major problems with that:
1. If the class you really want declared new instance variables, alloc 
will not have reserved the space for them.
2. A correctly-written init method will invoke [super init]. Invoking 
the superclass' init twice may be troublesome.


> I *THINK* 
> I've got it that it's the alloced object's init that runs. Now you tell 
> me that's wrong - it *IS* super's init that runs. ONE OF THESE RESPONSES

> IS WRONG, and I'll be damned if I can figure out which one!

No. Both statements are correct because the alloc'd object's class *is* 
super.


> I'm back to thinking I'm too stupid to be dicking around in OOP-land and
 
> I ought to just stick to straight C/Carbon. So much for having it 
> figured out... <sigh>

Don't give up. You're trying, and you *are* making progress. You *might* 
be trying to digest it in bites that are too large. Or overthinking 
things. Work on this - just this - for a little while:

MyButton* b = [[MyControl alloc] init];

will give you a fully constructed object of type MyControl. It will not 
give you a MyButton in any state; the runtime knows the class of any 
object it's looking at - because alloc establishes type information in 
one of NSObject's instance variables - and any messages you send to an 
object are resolved by looking at the definition for that class and then 
it's ancestors in order. The type of the variable into which it has been 
stored is meaningless.

It would be nice if the compiler would give you a warning but it can't 
because of the return type init methods use. What the compiler knows at 
build time isn't as complete as what the runtime knows during execution.

-- 
"Harry?" Ron's voice was a mere whisper. "Do you smell something ...
burning?"
   - Harry Potter and the Odor of the Phoenix