On Nov 8, 2011, at 9:57 AM, Andy O'Meara <andrew.ome...@soundspectrum.com> wrote:
> > 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? Yes, you are missing a fundamental difference between Objective-C and C++. There is one runtime for the entire application. Class definitions are loaded and registered with the runtime. The class is not defined by its symbol, it is defined by its named registration with the runtime. > 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. I agree that it would be nice to have namespaces for classes. However, that is not how the language is designed right now. You should file a radar asking for such support. > > 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. It can't be done now, but that doesn't mean it can't be done in the future. It all starts with filing bugs (and maybe a backwards-compatible proof of concept). --Kyle Sluder_______________________________________________ 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
