Re: remove -removeSubview:

[Quentin Mathé]

Le 27 avr. 2011 à 13:23, Banlu Kemiyatorn a écrit :

> On Wed, Apr 27, 2011 at 5:52 PM, Quentin Mathé <address@hidden> wrote:
>> If we support -setSubviews: and we try to leverage it as you suggest… 
>> According to Cocoa documentation -subviews doesn't return a defensive copy, 
>> hence in -removeFromSuperviewXXX we could retrieve the subviews with 
>> -subviews, remove the right subview from the returned array and then set its 
>> again with -setSubviews: without overhead (no array allocation or 
>> deallocation). Not sure the change is really worth the investment. It also 
>> contradicts the Cocoa documentation that states that -setSubviews: will call 
>> -addSubview: or -removeFromSuperview (and not the reverse).
> 
> Actually in my second mail I suggested to dereference the subview
> within -willRemoveSubview: hence, setSubviews should be somewhat
> higher level.
> 
> Not directly a patch, but probably something like.
> - (void) removeFromSuperview
> {
>       if (_superview == nil) return;
> 
>       if ([ [_superview subviews] containsObject:self] == NO) return;
> 
>       /* may be deallocated */
>       AANode *oldParent = _superview;
>       _superview = nil;
>       [oldParent willRemoveSubspace:self];
> }
> 
> - (void) willRemoveSubview: (id)subview
> {
>       [_subviews removeObject:subview];
> }

This looks like a bad idea, because NSView methods such as -willXXX or -didXXX 
are all delegate-like methods to be "implemented" in the subclass (you don't 
have to worry about calling 'super').

Cheers,
Quentin.