• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Using performSelector: on super
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using performSelector: on super


  • Subject: Re: Using performSelector: on super
  • From: James Bucanek <email@hidden>
  • Date: Tue, 5 Aug 2008 20:20:41 -0700

email@hidden <mailto:email@hidden> wrote (Wednesday, August 6, 2008 4:49 PM +0100):

Are you sure about that James?

No, I'm not. I apparently have lost the ability to read code. I read it as respondsToSelector:, not instancesRespondToSelector:.


[(id)super close];      // superclass assumed to implement close

Now that really would have saved everyone a lot of typing. I often
cast to a specific object type, casting with id never occurred to me.

It's also handy when you have a reference that typed as a formal protocol or an NSDistantObject, which makes the compiler complain about all mannor of things.


If you really want your code to dynamically alter execution depending on whether the close method is implemented by the superclass, I would suggest something like

try
{
[(id)super close];      // call superclass' -close, if implemented
...
}
catch
{
if (method not implemented exception)
// code that gets called if superclass doesn't implement -close
...
}
--
Exception handling might be a bit excessive here I think. If I recall
correctly It's quite a heavyweight object in Objective-C.

First rule of optimization: Don't!

Get the code working and profile it. Then if, and only if, it's a significant performance bottleneck THEN consider optimizing it.

The try/catch setup is well optimized and introduces very little overhead. So in the nominal case, where there is no exception, there's almost no overhead at all. Even if an exception was thrown, NSException is fairly lightweight. So unless you're calling -close a million times I seriously doubt it's going to cause a performance problem.

Having said that ... assuming [super close] isn't implemented and you're calling this 1,000,000 times and it's dragging your application into the mud, here's the fix:

static BOOL superMightImplementClose = YES;

if (superMightImplementClose)
{
try
{
[(id)super close]; // call superclass' -close, if implemented
...
}
catch
{
if (method not implemented exception)
superMightImplemtnClose = NO;
// code that gets called if superclass doesn't implement -close
...
}
}
else
{
// code that gets called if superclass doesn't implement -close
...
}
--
James Bucanek


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Using performSelector: on super
      • From: Ken Thomases <email@hidden>
References: 
 >Re: Using performSelector: on super (From: "email@hidden" <email@hidden>)

  • Prev by Date: How to debug a corrupted stack
  • Next by Date: Re: handling idle events
  • Previous by thread: Re: Using performSelector: on super
  • Next by thread: Re: Using performSelector: on super
  • Index(es):
    • Date
    • Thread