On 9 Nov 2011, at 05:21, Greg Parker wrote: > 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.
I agree, in NS::class, just substitute the ugly :: with _ and you see it's just a trick: NS_class. There should be a decent solution that doesn't need to put extra bookkeeping constructs in the language, and so that the clash is avoided in one place. Another point is that code in a class should not be bound to the environment and the C++ and Java way of doing it says 'environment' all over the place. A different approach is in Eiffel that identifies the problem as being when you try to use two libraries together and handles clashes in one place by renaming (in a configuration file separate from code). Thus it becomes a linker concern. Language design should keep compilation concerns separate from linking concerns (and indeed not just static linking, but dynamic run-time linking). On the other hand most Unix style C linkers really don't do enough to make sure things can be sensibly linked together, so the basic languages and compilers get bent instead and then programmers are forced to think of all these things at a lower level than they should need to. Similarly, imports and #includes are really bad, because they couple modules to their environment, rather than this kind of linkage being done externally in one place and handled by the linker. This means that if any import changes, you have to go through all the files and change all the imports and it looks like you are programming, but really you are not. So we invent a refactoring to take care of something that shouldn't exist. Anyway, that's my argument for not doing namespaces in Objective-C the Java or C++ way. There's not so much clutter in Java, but there is so much clutter in C++ it looks like Windows! I'm sure Apple will come up with a better solution and things they have done over the last few years with Objective-C (and tagged pointers in Lion as we have just discussed in the Obj-C group) have been very nice and simplifying (even for a language based on C). We should not force them into doing anything the same bad old way that everything else does. Ian _______________________________________________ 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
