[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about retaining delegates
From: |
Nicola Pero |
Subject: |
Re: Question about retaining delegates |
Date: |
Sun, 16 Dec 2001 21:51:33 +0000 (GMT) |
> > Recently I was bitten by the fact that NSBrowser does not
> > retain it's delegate. Now I can not easily check this
> > behaviour on OpenStep, but isn't this a bug?
> > I would expect that, because the NSBrowser needs
> > it's delegate later on, will retain the delegate.
> >
> >
> > Wim Oudshoorn.
>
> Well, the delegates are not retained, because they may "own" the
> objects whom they're delegate.
>
> Controller x owns NSWindow w ==> Controller x retains NSWindow w.
>
> Controller x is delegate of NSWindow w.
>
> If NSWindow w would retain its delegate, there would be a loop in
> the retain chain.
>
> The objects who send setDelegate: should remember to setDelegate:nil
> when they're going to be deleted (in their dealloc).
Yes! - exactly - I just wanted to add to this that there are other
cases/examples of this behaviour - setTarget: does not retain its
argument; other examples which pop to my mind immediately are
setDataSource:, setNextKeyView:, setPreviousKeyView: ... there are
certainly others.
The reason is always the same - the delegate/target/data source/whatever
might be retaining the object (directly or through a retain chain) - it
might even be the object itself! - so retaining the delegate/target/data
source/whatever might potentially cause a retain loop (the problem of a
retain loop being that nothing gets deallocated ever).