On Dec 13, 2014, at 11:06 AM, Maxthon Chan <m...@maxchan.info> wrote:
> What I am doing here is scanning all loaded classes for subclasses of a 
> certain class. Before any NSObject method can be issued I have to check if it 
> is actually NSObject or NSProxy derivative instead of an Object derivative 
> that does not support NSObject methods. This calls for runtime equivalent for 
> one of the following NSObject methods:

For what it’s worth we’ve run into this same problem at Omni— we have some code 
(that runs in debug builds, but not release builds, IIRC) that scans the class 
hierarchy. We simply ignore a bunch of classes that we’ve had problems with. 
This works, but it’s a little bit brittle because who knows when another class 
will appear in the runtime that can’t handle -respondsToSelector: and break 
your shipping application.


>         /* Some classes (that aren't our problem) asplode when they try to 
> dynamically create getters/setters. */
>         const char *clsName = class_getName(cls);
>         if (CLASSNAME_HAS_PREFIX(clsName, "NS") ||
>             CLASSNAME_HAS_PREFIX(clsName, "_NS") ||
>             CLASSNAME_HAS_PREFIX(clsName, "__NS") ||
>             CLASSNAME_HAS_PREFIX(clsName, "__CF") ||
>             CLASSNAME_HAS_PREFIX(clsName, "CA") ||
>             CLASSNAME_HAS_PREFIX(clsName, "_CN") ||
>             CLASSNAME_HAS_PREFIX(clsName, "VGL") ||
>             CLASSNAME_HAS_PREFIX(clsName, "VK") ||
>             strcmp(clsName, "DRDevice") == 0) {
>             /* In particular, _NS[View]Animator chokes in this case. But we 
> don't really need to check any _NS classes. */
>             continue;
>         }


On Dec 15, 2014, at 10:23 AM, David Duncan <david.dun...@apple.com> wrote:
> And also, if you are loading the bundle, then again there is little need to 
> do actual class walking as such, since you are in control of the bundle and 
> its formatting. Require the bundles to tell you the classes that are SKFormat 
> subclasses in the bundle’s property list and only use those.

IMHO this is the best approach to the problem.

Another approach is you could watch for the NSBundleDidLoadNotification and 
only scan the classes in the NSLoadedClasses entry. But I think that requiring 
the plugin to explicitly list the classes you should scan in its Info.plist is 
a good approach.




_______________________________________________

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