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
