Hello, Question for the cocoa experts here. I've googled around to no avail and lists.apple.com has been down for days(!). As ya'll know, when an app loads multiple bundles, the loader loads all the objC class name identifiers into a flat namespace, so ya can get that warning "Class ___ is implemented in both foo.bundle and bar.bundle. One of the two will be used. Which one is undefined." This issue shows up a lot, especially to us third party developers that have common objC utility/support classes that appear in multiple bundle-based products.
So the question of course is there any way to mark an entire objC class as being private (non-exported) to a bundle? I'm half shocked and half amazed that there seems to be no such way, in contrast to the compiler setting that C/C++ symbols can be set to be private by default. I feel like a radar really should be filed on this, or am I grossly missing something? That is, how can it be a good idea when things like the the OS X screensaver subsystem (or any app that uses 3rd party bundles) will inevitably have problems when two independent developers have two classes with the same name. And if you discount that case, then perhaps our case is more relevant, where as a third party that does author multiple bundles that are often plugins that get loaded side by side, causing this issue to surface. Yes, I know that one workaround is to mangle all objC class names based on something unique in the project (we are forced to do this with our screensaver products). I'd be more accepting of this if Xcode facilitated this (with perhaps a macro of or the introduction of @privateinterface or something), but I don't fancy the idea of having to stick nasty and limiting #includes, #defines, or #ifdefs all over our code to make sure stuff compiles and links correctly just to workaround the fact that objC seems like it should really allow classes to not be exported by default into a single/shared namespace. I suppose if there's no solution to this, then someone is going to describe how it can't be done because it would somehow break the loading of bundles. Well if that's the case, then I'm thinking that a radar is still worth filing because I'd be pretty surprised if the senior engineering level is going to agree that this whole flat objC namespace business is consistent with the precept that software should 'just work', rather than 'usually work' and emit user-attention-getting log messages as long as two internally private class names don't happen to have the same name. Thanks! Andy _______________________________________________ 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
