Re: remove -removeSubview:

[Quentin Mathé]

Le 27 avr. 2011 à 14:59, Banlu Kemiyatorn a écrit :

> ----- Original message ----- 
> > Banlu Kemiyatorn wrote: 
> > 
> > > > -removeSubview: is an NSView method and subclasses of NSView that 
> > > > override this method should call the super class implementation 
> > > > (unless they want to replace the functionality of -removeSubview:,  
> > > but 
> > > > I see no good reason for that). In all other classes there is no - 
> > > > removeSubview: method (unless you provide one yourself). I don't 
> > > > understand why you would need a check whether super implements that 
> > > > method. 
> > > 
> > > I think there is no -removeSubview: in Cocoa? 
> > > 
> > 
> > So what? -removeSubview: won't be called under Cocoa anyway unless you  
> > call it yourself. But then you probably shouldn't do that in a  
> > portable application because, uhmm, Cocoa doesn't implement that method. 
> 
> Not like that, for intance, if a cocoa app implement it in an nsview subclass 
> and didnt call super's removeSubview: and got recompile with GS then anything 
> in GS that call this nsview subclass's removeSubview:, assuming it is an 
> ordinary GS view, wont work properly. eg. 
> 
> AppView addSubview:aView then later 
> aView removeFromSuperview will invoke AppView's removeSubview: w/o calling 
> GS's 

I see what you mean, but the problem can potentially arise with all GNUstep 
additions, so it's really a border case. 
But I agree that it's a bit more dangerous than some other additions, since 
it's a primitive method which is called by various other NSView methods on 
GNUstep.

Just to be on the safe side, a possibility could be to turn -removeSubview: 
into a private method and rename it -_removeSubview:. This could complicate 
customizing the subview management behavior in a NSView subclass, but I don't 
believe so (other hooks such as -willRemoveSubview: are available).

Cheers,
Quentin.