Re: Calling -retain inside -dealloc
Re: Calling -retain inside -dealloc
- Subject: Re: Calling -retain inside -dealloc
- From: Andrew Garber <email@hidden>
- Date: Sun, 26 Jun 2005 23:48:59 -0700
That's exactly it Jeff :)
I just thought of another 2 solutions:
What if I subclassed NSMutableArray so that adding or removing objects
would affect the retain count of the objects?
Or how about adding a category to NSMutableArray which contains two
methods: -addObjectWithoutRetaining and -removeObjectWithoutReleasing?
Andrew
On 6/26/05, Jeff Laing <email@hidden> wrote:
>
> I don't know that this explained the problem well (which is a bit arrogant,
> since I'm just an interested bystander :-) so I'll clarify my understanding
> of what Andrew needs.
>
> Andrew has a class T.
>
> For architectural reasons, he also has an array somewhere which references
> every instance of T.
>
> Lets assume thats not optional for now.
>
> Its not a retaining array, or else his retain count will never go down to
> one without it also having been removed from the array.
>
> In [T init], the instance of class T will add itself to the array.
>
> He wants the retain/release mechanism to automatically remove the reference
> whenever T is finally dealloc'd
>
> This is a pattern that I have needed in the past as well, so I'd be
> interested in alternate solutions. Personally, I find the 'unref it whenever
> [T release] is called' a little nasty tasting, but it does seem to be the
> lightest-weight solution.
>
> I'm not certain that there is really a need for T to be left in the array
> until the final release is called - I'm sure that at some point, the
> application realises that it no longer wants to talk to the T and it could
> explicitly remove it then, rather than potentially have the T instance hang
> around a log longer (perhaps in an autorelease pool), and thus get his
> callbacks firing in "almost dead" instances. But thats beside the point,
> from the discussion of the abstract pattern which I'd like to see continued.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden