Yes, that's what I do. I call NSClassFromString(@"NSPredicateEditor") and create one of two classes depending of call's result. Each class loads its own NIB and this should guarantee me that I never call unsupported code.
Thanks for the explanation. On Sun, Jan 18, 2009 at 3:23 PM, Ken Thomases <k...@codeweavers.com> wrote: > On Jan 18, 2009, at 4:15 AM, Vitaly Ovchinnikov wrote: > >> Well, after reading your link one more time, I found this: >> >> http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/Using/chapter_3_section_4.html#//apple_ref/doc/uid/20002000-1114537 >> >> So, I am right for Tiger and Leo, that OSX uses lazy loading and if I >> never call NSPredicateEditor-related code, I will have no problems on >> Tiger? > > Basically correct. The term you want to focus on is "weak linking", rather > than "lazy loading". > > When you compile with the 10.5 SDK but set a deployment target of 10.4, then > any symbols which are new to 10.5 will be linked weakly. At load time, the > dynamic loader (dyld) will not prevent your program from loading just > because weak symbols can't be resolved. > > Then it's your code's responsibility to avoid using the missing > functionality. Your strategy of using different nibs is one way to achieve > that. Using -respondsToSelector: for Objective-C methods is another tool. > For functions or variables, you need to test if the address of the symbol > is not NULL before using it. > > Regards, > Ken > > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
