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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev