Unfortunately the problem is that when you sell and ship commercial software, shipped software can't look into the future. The real aspect of this issue, that I raised in my initial post, 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 surfaces.
And yes, this thread does belong on the objC list and will be moving it there (I didn't realize there was a objC list when I originally posted). On Nov 9, 2011, at 12:08 AM, Karl Goiser wrote: > I think there is another solution that doesn’t involve making the language > more complicated: > > I would complain to the suppliers of the bundles with conflicting class names. > > They know they are delivering into an environment with a flat namespace. It > is up to them to defend against this sort of problem. It’s their fault that > this problem is occurring. > > > Karl > > _______________________________________________ > > 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/andrew.omeara%40soundspectrum.com > > This email sent to andrew.ome...@soundspectrum.com _______________________________________________ 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
