Interesting, thanks. I think the side of this that typical OS X developers is that their own internal classes from multiple bundle products are the bulk of the issue, not for the objC bundle loading mechanism to get a fancy namespace overhaul (which is understandably a huge undertaking). I suppose what we've discovered--or at least what I've discovered--in this thread is that because addressing this issue is so huge from the namespace spec side, the answer seems to be the path of expanding @private to mark up an entire class. Depending on the mechanics and details of how the objC binary is structured, the bundle's linker would either omit the names of those classes from the symbol list or it would emit a flag, indicating that the loader should skip that class entry. The former makes more sense for security/snooping reasons (and to people who don't see the value in that, allow me to suggest that quite a lot can be learned about an app or bundle by looking through its class and method tables).
Speaking of that, to folks here that think this stuff is boring or isn't relevant to their products, please take a moment and realize that every objC class and method name are public and completely visible to anyone that owns a text editor (let alone a decent disassembler). Still don't care? Well, if you have a serial number/license scheme, copy-protection scheme, crypto, or payment mechanisms that use objC, then realize they're on display for everyone to see. We make cross-platform software, so the bulk of our code is in C++ frameworks, but most projects out there have god and country exposed for the world to see and their authors often don't even realize it. Worse, the default setting in Xcode is for all C/C++ symbols to be exported by default so add that to the mix too. Admittedly, we care about these issues more than the next dev because we sell software in one of the most highly pirated areas of software, but hopefully bringing this up here helps raise some awareness from devs that don't normally think about this stuff. Happy trails! On Nov 9, 2011, at 2:54 AM, Jean-Daniel Dupas wrote: > > Le 9 nov. 2011 à 09:14, Andy O'Meara a écrit : > >> >> >> 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). > > > Before starting a discussion on the obj-c list, you may want to read the > following thread from the clang mailing list: > > http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-November/012026.html > > It may contain good answers to your questions about obj-c namespaces. > >> 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/devlists%40shadowlab.org >> >> This email sent to devli...@shadowlab.org > > -- Jean-Daniel > > > > _______________________________________________ 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
