> Le 15 déc. 2014 à 19:45, Fritz Anderson <fri...@manoverboard.org> a écrit : > > I can be dense. Do I understand correctly that > > - You have an application that ideally should run continually. > > - It accepts plugins that provide one or more classes. > > - Those classes must at least observe a protocol; otherwise there would be no > sensible way to use them. > > - They must have unique names. > > - As is typical of ObjC plugins, the classes are packaged in a dynamic > library; and as is typical, the library is wrapped in a package directory, > which your application has registered with Launch Services as a package, of a > certain type and edit/view/associate relationship to your application. I'm > sure this is so in your case, as plugins typically need to carry resource > files.
Just for the record, typical Obj-C plugins are packaged in loadable bundle (MH_BUNDLE), which are a different binary object kind than dynamic library (MH_DYLIB). > - If a package, the plugin might carry an Info.plist file — plugins commonly > do. > > - You mean to load and unload plugins dynamically, as they appear and > disappear in a designated directory, without interrupting the application. > > Do I follow you so far? If so, I have some comments. > > You can't unscramble the egg: Dynamically-loaded classes can be loaded any > time you like, but they cannot be reloaded or unloaded. Surely you know this; > surely I misunderstand (or am behind the times). > > If you are (practically) committed to a package structure with an Info.plist, > why can't you add an <array> key listing the names of the provided classes? > Or for that matter, a text file containing the names? That's one of the > things NSBundle is for. It is a universal practice. "Just works" is a great > ideal, but one can expect someone who knows how to build a dynamic library to > understand such things. > > The declared classes might not implement the required methods, but that's > easy and safe to detect once they are loaded. If you must reject, your duty > ends when you log the problem and put up an alert. > > Am I missing something? > > — F > > >> On Dec 15, 2014, at 11:59 AM, Maxthon Chan <m...@maxchan.info> wrote: >> >> What I am doing here is to determine a format handling class based on file >> extension. I want to achieve a drop-to-plugin-folder-and-it-will-work effect >> and allow one plugin to include multiple format handling classes. Also since >> I am creating an open system I don’t want to require other plugin writers to >> register their classes, instead the main code shall discover plugins on its >> own. >> >> This means that the main code will not be able to call any plugin classes >> methods so +initialize never get called. Also your approach means that the >> main code will hold a strong reference to the plugin code which prevents >> plugin unloading. >> >> Class walking may be fragile, but it is fragile enough to allow plugins to >> come and go easily without having to restart the main code. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
