On Dec 13, 2014, at 11:06 AM, Maxthon Chan <[email protected]> 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 <[email protected]> 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 ([email protected])
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 [email protected]
