[cfe-dev] Adding namespaces to Objective-C

[Owen Shepherd]

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.
> 
>> 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

> 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 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.

>> 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). 

> 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. 

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