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: Erik Buck <email@hidden>
- Date: Fri, 9 Dec 2005 13:43:12 -0500
Protocols support inheritance.
Today you may have MYPluginTypeAProtocol and MYPluginTypeBProtocol.
Simply check for protocol conformance. If the plugin developer's
adopt the protocol, the compiler will warn them if not all protocol
methods have been implemented before they ever try to load a plugin.
In the future, you may invent MYPluginExtendedTypeAProtocol that
inherits from MYPluginTypeAProtocol.
When that happens, ask each plugin if it conforms to
MYPluginTypeAProtocol. If it does, then ask the plugin if it
conforms to MYPluginExtendedTypeAProtocol. The best thing to do is
report to the user that only MYPluginTypeAProtocol compatible
operations are possible, but if the plugin is upgraded to conform to
MYPluginExtendedTypeAProtocol, your application can do more with the
plugin.
Alternatively, add a -protocolVersion method to all of your
protocols. Use protocol inheritance but require that plugins using
the extended protocol return a higher version number than plugins
using the original version. Right after you check for protocol
conformance, check the -protocolVersion and make decisions based on
that.
Alternatively, consider not using protocols at all for plugins. At
plugin load time, either explicitly check for each needed method via -
respondsToSelector: and report missing methods, or simply provide a
base class within your application that all plugins must inherit. If
you provide good default behaviors in your base class, you may not
have to do any plugin validation at all or only an -isKindOfClass:
check.
Alternatively, consider using a scripting language such as Python,
Tcl, or Ruby for plugin development. Each of these languages
integrate well with your Objective-C AppKit application. They
simplify plugin creation for you users and reduce the number of
things that can go wrong.
_______________________________________________
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