Le 27 avr. 2011 à 13:23, Banlu Kemiyatorn a écrit : > On Wed, Apr 27, 2011 at 5:52 PM, Quentin Mathé <[email protected]> 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. _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
