• 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 15:38:34 -0700

email@hidden <mailto:email@hidden> wrote (Tuesday, August 5, 2008 2:19 PM +0100):

Sorry for the inaccuracy.

No problem.

I of course mean that the SuperSocket class responds to the -close
method but does not declare it in its interface file. -close is indeed
declared as a method on a SuperSocket category defined within
SuperSocket.m

I was using performSelector: merely to keep the compiler content.
Declaring a further accessible category on SuperSocket to announce the
existence of -close accomplished the same thing.

Then let me make two points and one suggestion.

In your original code, you had

    SEL closeSelector = @selector(close);
    if ([SuperSocket instancesRespondToSelector:closeSelector]) {
        ...

This does not, as I think you believe, test to see if an object of the class SuperSocket responds to the -close message. In fact, it tests to see if the class object for SuperSocket responds to the +close message. SuperSocket is a reference to the single Class object defined for SuperSocket, it it not a proxy for an instance of the SuperSocket class.

To determine if an instance of an object SuperSocket responds to a particular method, I believe that you'd have to use SuperSocket's Class object reference and use class_getInstanceMethod to determine if it actually implements a -close method. If you wanted to find out if any of its superclass' implemented it, you'd have to walk of the chain of parent Class objects until you hit NSObject.

As for the compiler warning, that could easily be suppressed with (believe it or not)

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

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
...
}
--
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: "email@hidden" <email@hidden>
    • Re: Using performSelector: on super
      • From: Charles Steinman <email@hidden>
References: 
 >Re: Using performSelector: on super (From: "email@hidden" <email@hidden>)

  • Prev by Date: Re: Properties and memory management
  • Next by Date: Re: Using performSelector: on super
  • Previous by thread: Re: Using performSelector: on super
  • Next by thread: Re: Using performSelector: on super
  • Index(es):
    • Date
    • Thread