> > > <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. >
Cool, thanks for posting Greg. Yeah, there seems to be a lot roadblocks to dealing with this, but my point was more to suggest that simply allowing bundles to only publish classes explicitly is an easy way to address that it's generally the *support* classes that need to be private/hidden by default. I think developers will do a good job to ensure that exported class names are unique, but it's all a developer's *support* classes that are likely to have issues. The aspect of concern of this issue is that third party developers such as ourselves internally reuse various support classes for multiple bundle products, so when the host loads our products this issue always appears, users panic over log messages they don't understand, and dork OCD devs like me feel icky that the namespace is being spammed unnecessarily. So as you initially pointed out, I've gone with making a C mangler macro approach. It wasn't too painful, but I do think it is a bit of an oversight that there's no way to disable all objC classes from being public by default. 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
