Re: ObjC's flat and all-exported namespace, help!
Re: ObjC's flat and all-exported namespace, help!
- Subject: Re: ObjC's flat and all-exported namespace, help!
- From: Greg Parker <email@hidden>
- Date: Tue, 8 Nov 2011 10:21:25 -0800
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 email@hidden Runtime Wrangler
_______________________________________________
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