This should be on the Obj-C list. This whole discussion is about the language implementation. The Obj-C list needs more love anyway.
On Nov 9, 2011, at 10:30 AM, Jean-Daniel Dupas wrote: > > Le 9 nov. 2011 à 01:37, Ian Joyner a écrit : > >> 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. > > Objective-C uses a dynamic runtime. The linkers (both the static one and the > dynamic one) cannot take care of all possible cases. > How do you handle NSClassFromString used with a non constant string ? > >> 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. > > -- 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
