On 30 May '08, at 11:55 PM, Bill Bumgarner wrote:
On May 30, 2008, at 11:43 PM, Jens Alfke wrote:If you actually want to ask a question of your class's superclass, you have to do so directly:[[[self class] superclass] instancesRespondToSelector: aSelector]Well... yeah... you *can* do that.But *don't do that*. (And I know Jens knows better -- I'm just pointing something out).Any code that relies upon *skipping* super's implementation of something to get something done is just asking for trouble.
No, that's not what it's for. There are situations where you implement a method, and you want to call the superclass implementation ... but only if there _is_ one, since otherwise that would raise an exception.
This comes about with those @$&% "informal protocols" that pollute the namespace of NSObject. So for example, let's say I subclass NSFoobarControl and implement -awakeFromNib. Now, should I call [super awakeFromNib] first? If NSFoobarControl implements that method, then yes I'd damn better do so, otherwise I screw up the superclass's state. But if it doesn't, that super call will raise an exception.
One solution is to put in the 'super' call, and then try running your code. If that call blows up, take it out. That's really brittle, though, since who knows if NSFoobarControl will change in 10.6 to have an -awakeFromNib method? If it does, suddenly my app might crash on 10.6, and that might be really hard to track down.
The only reasonable solution seems to be to do exactly what I said — check whether the superclass implements the method before calling it.
—Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
