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.

> On Dec 15, 2014, at 20:42, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
> 
> 
>> Le 15 déc. 2014 à 13:31, Uli Kusterer <witness.of.teacht...@gmx.net> a écrit 
>> :
>> 
>> On 15 Dec 2014, at 12:42, Jean-Daniel Dupas <mail...@xenonium.com> wrote:
>>> I found only 5 classes that does not responds to isProxy and they are all 
>>> internal classes, so real code will never have to deal with instances of 
>>> such classes.
>> 
>> Maxthon is iterating over the classes in the system. Even internal classes 
>> to the OS show up in that list, so I really don't see how he would *not* 
>> have to be able to at least deal with their presence.
>> 
> 
> Fair enough, but I didn’t got any issue while dealing with theses classes. I 
> managed to query if they responds to a selector, got there superclass and 
> more.
> 
>> Apart from completely re-thinking his approach. E.g. NSImageRep, AFAIK, 
>> simply has each image representation subclass add itself to an NSArray from 
>> its +initialize method. I'd think that'd be less fragile than walking the 
>> entire class list.
> 
> I fully agree on that. Relying on class iteration is generally a design flaw. 
> It is too fragile to be used in a reliable and futur proof way.
> But I don’t think you can rely on +initialize to register subclasses as 
> initialize will not be called until the someone try to use the target class 
> (or one of it’s subclass).
> 
> You can use +load but should probably be careful when doing so as there is no 
> guarantee about the class loading order AFAIK. 
> 
> 
> _______________________________________________
> 
> 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/max%40maxchan.info
> 
> This email sent to m...@maxchan.info

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________

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

Reply via email to