• 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: run-time list of selectors in protocol?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: run-time list of selectors in protocol?


  • Subject: Re: run-time list of selectors in protocol?
  • From: William Turner <email@hidden>
  • Date: Fri, 9 Dec 2005 12:57:09 -0500

Here's why I am interested in doing this...

We are developing an application with a number of plugin interfaces. The customer is government, so I can't go into much detail about what the app does, but one requirement is that it be as easy as possible for third parties to develop the plugins. Currently there are 2 plugin types, with an expectation that we will add 1-2 more. Each plugin has its own protocol. The protocols are more or less finalized, but could possibly need modification down the road. Currently, the app attempts to determine which plugins are available at launch time. This involves, among other things, verifying that each potential plugin conforms to the appropriate protocol(s). This where my question comes into play.

Currently, the app simply calls "conformsToProtocol:" on the main class in each plugin bundle. If this call returns "YES", all is well. If it does not, the app cannot offer any detailed information regarding the cause. It seems to me that it would be helpful to plugin developers if the app could report the method(s) which have not been implemented. In case the protocol had to be updated in a later version, this would assist the upgrade of plugins as well. So, I'd like to be able to check the protocol methods on an individual basis - this I could do by hardcoding a check for each method with respondsToSelector: or instancesRespondToSelector:, but it would be nice, when more protocols are added and existing protocols are updated not to have to modify the code which does the checking.

Maybe there's a better design decision - I'm completely open to any suggestions - but I don't think the general intent is too unreasonable.

Wil

On Dec 9, 2005, at 12:09 PM, Damien Bobillot wrote:


Le 9 déc. 05 à 17:54, Jeff LaMarche a écrit :

On Dec 9, 2005, at 11:51 AM, William Turner wrote:

Is there a way I can query a protocol at run-time to get a list of the selectors it includes?

On a related note, is there a way to get more detailed information when a class fails to "conformToProtocol"?

I'm having trouble envisioning a situation where you would need to know at runtime what methods a protocol contains. This seems like it's going to be primarily a compile-time issue.

You can always look at the protocol's header files, which you'll find inside the framework that contains it. Although compiled frameworks do not have the source code, they do have the header files, which should list all the required methods. If it's an Apple-supplied protocol, you can also just use XCode's documentation browser or AppKiDo to find out how to conform to the protocol.

I agree with Jeff : needing to access to the list of available methods in often du to a bad code design. In most case, using conformToProtocol: or respondToSelector: in far from sufficient.

However, if you think you are in really special case, look at the Objective-C runtime introspection functions :
http://developer.apple.com/documentation/Cocoa/Reference/ ObjCRuntimeRef/index.html

--
Damien Bobillot

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden
  • Follow-Ups:
    • Re: run-time list of selectors in protocol?
      • From: Damien Bobillot <email@hidden>
References: 
 >run-time list of selectors in protocol? (From: William Turner <email@hidden>)
 >Re: run-time list of selectors in protocol? (From: Jeff LaMarche <email@hidden>)
 >Re: run-time list of selectors in protocol? (From: Damien Bobillot <email@hidden>)

  • Prev by Date: Re: adding an executable as a resource
  • Next by Date: Re: create a bufferarray from a string
  • Previous by thread: Re: run-time list of selectors in protocol?
  • Next by thread: Re: run-time list of selectors in protocol?
  • Index(es):
    • Date
    • Thread