Re: Question about retaining delegates

[Nicola Pero]

> > 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).