[cfe-dev] Adding namespaces to Objective-C

[Owen Shepherd]

On 9 Nov 2010, at 22:15, David Chisnall wrote:

> I proposed a mechanism for adding namespaces to Objective-C a short while ago, so I'll add some comments here:
> 
> On 9 Nov 2010, at 21:54, Owen Shepherd wrote:
> 
>> 
>> On 9 Nov 2010, at 20:25, Chris Lattner wrote:
>> 
>>> On Nov 9, 2010, at 9:47 AM, Owen Shepherd wrote:
>>>> As someone interested in contributing to Clang - and, in particular, contributing to its Objective-C(++) support, I would like to hear people's thoughts with regards to adding support for namespaces to Objective-C.
>>> 
>>> Hi Owen,
>>> 
>>> We've considered adding namespaces to ObjC many times in the past.  It hasn't happened so far largely due to the fact that we really want a unified way to get selectors and classes into namespaces.  Just getting classes into namespaces doesn't solve the whole name conflict issue.
> 
> The largest problem with conflicting selectors is when you define new ones with different types.  This is already solved in the GNUstep problem.  The secondary problem, of overlapping categories, would be better solved by adding class boxes to the language than trying to hack them into namespaces.  Indeed, class boxes would be a more interesting addition than namespace in general.

Can you link to references to how GNUStep solves this?

>>>> Some thoughts:
>>>> 1.	 Do we make this an extension to Objective-C, or to C itself? From my point of view, each way primarily boils 
>>>> 	down to a matter of syntax: As an Objective-C extension, the keyword would likely be "@namespace"; while 
>>>> 	as a C extension it would probably be "__namespace__" (or maybe just "namespace" in a hypothetical 
>>>> 	"clang99"  mode)
>>> 
>>> This is another big issue.  There aren't a lot of good answers here.  If you decide that it should be added to C, then it is logical that C and C++ namespaces work the same way.  If you do this, then you're changing the behavior of existing ObjC++ code that does:
>>> 
>>> namespace abc {
>>> @interface xyz
>>> 
>> 
>> Perhaps the best option is to make these extensions optional, and when not enabled to generate a warning about incompatibility of such declarations
> 
> Adding namespaces to C requires some kind of name mangling, so it introduces all sorts of compatibility problems (much like the problems that plagued C++ compilers for years).  

Name mangling caused (and causes) C++ problems because C++ does not specify the name mangling. There is no reason we cannot specify the name mangling for such namespaces. However, even if we did not, it is likely we would not have similar issues since we would also be providing a reference implementation.

>>> If you make it *objc only* (e.g. "@namespace") then it really can only apply to classes, which makes the extension fit even more poorly into the language (why classes but not globals, functions, or selectors?)
> 
> I don't see applying it to anything other than classes makes sense.  Objective-C is a hybrid language.  Once you are in 'object land' (as Tom Love described the stuff inside square brackets), you don't expect things to behave in the same way as they do outside.

Namespaces are a property of types, of which objects are just one form. Your average framework is not just made of objects; there are often ancillary types (To pluck one off the top of my head, CoreGraphics' CGFloat is an example)

>> I was referring more as to whether it would be supported in C, or in Objective-C only. Supporting C also would seem more satisfying.
>> 
>>> Depending on how crazy you get, you could imagine coming up with some sort of way to retroactively make NS::Object resolve to NSObject or something.
>> 
>> The obvious solution would seem to be to move the classes into the NS namespace, then make the compatibility layer do "@interface NSObject: NS::Object" for each of the classes.
> 
> That would be a terrible idea.  As is using : in separators, as it is already used in selectors (including double-colons).  One of the key design goals of Objective-C was that new semantics should ALWAYS have new syntax (Apple completely disregarded this with property accessors, which is why there was so much hostility to these).
> 
> I proposed that namespaces should be able to declare a short form, as well as the long form, e.g.:
> 
> @namespace Foundation (NS)
> @interface Object ...
> 
> Would declare the Object class in the global namespace as NSObject, and in the Foundation namespace as Foundation!Object.  The runtime functions for iterating over classes would only see the version in the global namespace and a set of new functions would provide introspection.

The :: syntax is unambiguous, familiar, and common with that of C++. I see no reason to be distinct for the sake of it. As for short aliases, I see no reason why one could not do

namespace Foundation { @interface Object ... }
using NSObject = Foundation::Object;

Longer? Slightly. However, it provides the option to avoid polluting the global namespace in the general case, something which is always useful.

> 
>>>> 2.	Function name mangling. Function names follow the platform's C++ ABI (Much like the existing 	
>>>> 	__attribute__((overloadable)) does*
>>>> 3.	When class names are involved in Objective-C symbols, then namespaced classes are mangled similarly to 
>>>> 	C++ names are; a hypothetical MyNS::MyClass is mangled as 4MyNS7MyClass. This is backwards 	
>>>> 	compatible; traditional class names cannot start with numbers
>>>> 4.	The added namespace declarations are equivalent to and interchangeable with C++ " namespace" 
>>>> 	declarations. 
>>> 
>>> Yes, making it as similar as possible to c++ namespaces is the only way to go.  However, you probably don't want argument dependent lookup (aka Koenig lookup), right?  What other things would be different?
>> 
>> Lookup would always select the entity of the same name in the closest scope, correct. The intention is that code which is valid (Obj)C would always be valid (Obj)C++ (though obviously not the converse). 
> 
> Lots of ObjC is not valid ObjC++ already; unlike ObjC, C++ is not a pure superset of C.

ObjC is only invalid ObjC++ in the same cases when C is not valid C++. We should not work to increase the incompatibility.

> Mangling ObjC class names is very messy, because Objective-C classes are exposed to introspection.  They are not exposed as global symbols (necessarily - they are in some implementations, but they are already mangled there and the mangling is private and not part of the language).

When exposed to the user, the mangled names would not be used (unless unavoidable). Foundation::Object would be called "Foundation::Object".

> Making it interchangeable with C++ namespaces also seems like a mistake.  What problem does this solve?  Objective-C classes are not interchangeable with C++ classes, neither are ObjC exceptions and so on, so why should namespaces?

Why should they not be interchangeable? Having two duplicate functions just adds complexity to implementation and to use. Plus, with Apple's 64-bit runtime (And I presume also modern versions of the GNU runtime?), the exception model is unified. 

In many regards, Objective-C classes are the odd one out, and I see no reason - in the long run - to not support their unification (though it is indeed a tricky problem).

> 
>>> Adding namespaces to ObjC is a huge minefield, not something to be done lightly.  If you'd really really like to pursue it, please start by writing out a spec/proposal of how you think it should work along with the corner cases enumerated.
>> 
>> I am drafting one now, though it may take a while.
>> 
>> The hardest aspect seems to be namespacing of selectors; it seems to be an issue which I haven't really seen affecting other languages, and seems a rather difficult one to solve elegantly, though I must ask: Is it a major issue in practice? I haven't found it to be, and haven't found other people claiming it to be either, though I don't claim that it doesn't exist. 
> 
> See the classboxes concept from the University of Berne.  I'd love to see ObjC get support for classboxes, but it would require massive changes to the runtime and I have yet to come up with a way of doing it that wouldn't harm performance considerably.
> 
> David


I must say that classboxes are an interesting concept, though the performance issues shown are certainly discouraging.

-- Owen Shepherd
http://www.owenshepherd.net/
owen.shepherd at e43.eu (general) / oshepherd1 at shef.ac.uk (university)