Re: WTF is happening?
Re: WTF is happening?
- Subject: Re: WTF is happening?
- From: Wim Lewis <email@hidden>
- Date: Mon, 15 Dec 2014 14:25:07 -0800
On Dec 13, 2014, at 11:06 AM, Maxthon Chan <email@hidden> 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@hidden> 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@hidden)
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:
This email sent to email@hidden