[cfe-dev] Adding namespaces to Objective-C

[Douglas Gregor]

On Nov 9, 2010, at 3:54 PM, 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.
>> 
>>> 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.

It's not interesting for C unless the ISO C committee would eventually want that. I highly doubt they'd be interested.

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

This doesn't work, because you've established inheritance but not equivalence. Some NSObjects will be NS::Objects, and that (when extended to many objects as they move into namespace NS) is going to break code.

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

Well, you probably don't want argument-dependent lookup, except perhaps for selectors. 

	- Doug