On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: > 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.
This is the only solution. > 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. <rdar://problem/2821039> ER: Objective-C namespaces If you're familiar with Radar numbers, you'll recognize that the bug is very old. The name is a bit misleading - C++ namespaces or Java packages are little better than adding name prefixes by hand. (For example, they don't solve the problem of two developers importing the same static archive.) A real solution for class name collisions needs to be (1) automatic or nearly so, (2) predictable so nib references work, and (3) not incompatible with existing classes. It's a hard problem. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ 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
