Re: run-time list of selectors in protocol?
Re: run-time list of selectors in protocol?
- Subject: Re: run-time list of selectors in protocol?
- From: Damien Bobillot <email@hidden>
- Date: Fri, 9 Dec 2005 19:26:53 +0100
William Turner wrote :
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:,
It's what is widely used, and proposed in apple's documentation :
http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingCode/
Concepts/Plugins.html
http://developer.apple.com/documentation/Cocoa/Conceptual/LoadingCode/
Tasks/UsingPlugins.html
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.
You may create an abstract class, used as a base for each plugin
types. In this case, you may create default implementation.
Another solution is to override the doesNotRecognizeSelector: method
in every plugin class to avoid runtime errors when a method is not
yet defined.
Both ideas are only for a development phase, and should be suppressed
as much as possible in the final product.
--
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