Adding namespaces to Objective-C

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.

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

Do any other people have any comments, or any thoughts on how best to stage this?

* At least for a first pass. It would seem prudent to define a different name mangling scheme for C namespaces long term. Perhaps we again take advantage of the illegality of numbers at the start of identifier names and mangle function names the same way we do classes?

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

P.S. Any estimates on when the official Git mirror will be available? I find Git to be incredibly useful for managing one's changes outside the official repository.

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

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

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.

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?

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.

-Chris

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@e43.eu (general) / oshepherd1@shef.ac.uk (university)

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

I proposed a mechanism for adding namespaces to Objective-C a short while ago, so I'll add some comments here:

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.

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

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.

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.

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.

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

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?

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 have had a spec for this for several years.

The gist is that methods are defined by the protocol, class, or category, and are currently implicitly reused; syntax would have to be added to disambiguate re-use (i.e. @overrides or equivalent) from introductory use, and to occasionally explicitly name the source of the method being used (for example, -copy is defined in NSObject from the NSCopying protocol, but NSObject does not conform to the NSCopying protocol; Java had the same issue with clone() IIRC). C# (CLR) has the equivalent to @introduces. The problem is that without this, a subclass that extends some other providers class gets burned if the superclass evolves over time and inadvertently introduces a method name already in use by the subclass.

A key concern is space representation; also that when qualified selectors are dispatched and would otherwise match if not for the qualifier, dispatch still occurs, although perhaps at a speed penalty.

If/when classes/protocols/categories get further namespace delineation (which is what you are proposing) the natural path is to extend it to selectors.

By my reasoning, namespaces for selectors raise additional mostly orthogonal issues to namesakes for classes/protocols/categories. Since ISO C is unlikely to be interested in namespaces, I also reason that a pure ObjC solution is acceptable, and it may be sufficient to only allow a two-level namespace that matches the Framework level packaging. C++ interoperability in ObjC++ probably trumps that though.

Changes such as this must also consider whether and how an ABI needs to be changed.

Food for thought.

Blaine

I proposed a mechanism for adding namespaces to Objective-C a short while ago, so I'll add some comments here:

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@e43.eu (general) / oshepherd1@shef.ac.uk (university)

FWIW, NSCopying defines only one method which is -copyWithZone:. -copy is not defined in NSCopying, this is just a convenient NSObject's method that return [self copyWithZone:nil] or raises an exception.
That's why I always use copyWithZone:nil in my code. It allows the compiler to detect if you try to copy an object that do not conform to NSCopying.

-- Jean-Daniel

FWIW, :: is not a token in ObjC.

-Chris

No, but it may be used in selector.

@selector(foo::::slight_smile: is a valid selector. So, if namespace applies to selector too, you will have to figure a way to define qualified selector name.

-- Jean-Daniel

Or side-step the problem by using something other than "." in the equivalent of nested-name-specifiers.

  - Doug

I proposed using !, as in Apple!Foundation!Object. This has the advantage that ! is not a valid suffix or infix operator, so there is no ambiguity - you never see ! after an identifier in normal ObjC code.

David

-- Sent from my IBM 1620

How about the backslash?

Sean

I'll point out that the syntax is the least interesting of the problems facing the idea of retrofiting namespaces into objc... :slight_smile:

-Chris

My two cents

I am not a man who can decide this, …
but I very love Objective C especially for its simplicity, nice syntax, c99 compatibility, in short the things c++ has not. I believe we must keep in mind and Objective C these. Fortunately Objective C is not a c++, if you prefer one write in c++.

I think prefixes are more beautiful than namespaces (by the way they are simple for runtime support ;-). There is no diversity between NSSet or NS::Set, excepting one or more unnecessary letters, so why? The namespaces do not increase the culture, then if prefixes can conflict so namespaces can likewise.

I guess the interesting problems are for instance: automatic IMP cashing, operator overloading

NSNumber *sub = [[i - j] / z];

Objective-C at present doesn't give you a choice. Your namespace must be short, or else be very cumbersome to use. Hence, everyone uses 2 character prefixes (or 3 at most), which are prone to clashes.

On the other hand, if namespaces were supported, it is likely that NSObject would be called something along the lines of Foundation::Object, and other libraries would also use longer namespace names. This would not make programs any longer due to features such as "using namespace" and/or namespace aliases (e.g. something along the lines of C++0x's "using NS = Foundation", or even "using F = Foundation") and the ability to import entities from one namespace into another (e.g. "using Foundation::Object").

Namespaces give us the ability to have longer entity names, without the inconvenience this would normally cause.

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

Everyone strongly discourages the use “using namespace” since the objects from tens used namespaces can clashes, well then to make short namespace names we can use aliases, but would they clash like prefixes?

I think prefixes are more beautiful than namespaces (by the way they are simple for runtime support ;-). There is no diversity between NSSet or NS::Set, excepting one or more unnecessary letters, so why? The namespaces do not increase the culture, then if prefixes can conflict so namespaces can likewise.

Objective-C at present doesn’t give you a choice. Your namespace must be short, or else be very cumbersome to use. Hence, everyone uses 2 character prefixes (or 3 at most), which are prone to clashes.

On the other hand, if namespaces were supported, it is likely that NSObject would be called something along the lines of Foundation::Object, and other libraries would also use longer namespace names. This would not make programs any longer due to features such as “using namespace” and/or namespace aliases (e.g. something along the lines of C++0x’s “using NS = Foundation”, or even “using F = Foundation”) and the ability to import entities from one namespace into another (e.g. “using Foundation::Object”).

My and your code will be incompatible if we choose NS, N, or something instead of Foundation:: We increase issues and look how we can eliminate them.

Everyone strongly discourages the use “using namespace” since the objects from tens used namespaces can clashes, well then to make short namespace names we can use aliases, but would they clash like prefixes?

Indeed, though there are other useful uses of it (e.g. before C++0x’s “inline namespaces” support, I have used it in order to give binary incompatible versions of a library different symbols). It is also perfectly acceptable for the library implementer to do

I think prefixes are more beautiful than namespaces (by the way they are simple for runtime support ;-). There is no diversity between NSSet or NS::Set, excepting one or more unnecessary letters, so why? The namespaces do not increase the culture, then if prefixes can conflict so namespaces can likewise.

Objective-C at present doesn’t give you a choice. Your namespace must be short, or else be very cumbersome to use. Hence, everyone uses 2 character prefixes (or 3 at most), which are prone to clashes.

On the other hand, if namespaces were supported, it is likely that NSObject would be called something along the lines of Foundation::Object, and other libraries would also use longer namespace names. This would not make programs any longer due to features such as “using namespace” and/or namespace aliases (e.g. something along the lines of C++0x’s “using NS = Foundation”, or even “using F = Foundation”) and the ability to import entities from one namespace into another (e.g. “using Foundation::Object”).

My and your code will be incompatible if we choose NS, N, or something instead of Foundation:: We increase issues and look how we can eliminate them.

Lets say I make a library “MyLib”, and you make the library “YourLib”. If I do
MyLib.h:
namespace MyLib {
using F = Foundation;

@interface MyClass : F::Object {
};
@end
}

MyLib.m:
using namespace MyLib;

@implementation MyClass

then we have no danger of collision.

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

My two cents. Let’s absolutely positively not have namespace for objective-c.

  1. Somehow c has survived 30+ years not needing namespaces. I am told that it is not on the table yet.
    When, and if, namespaces appear for c, it can extend to objc as needed.
  2. For objective-c++, make objective-c live, and thrive, using c++'s namespace.
  • fariborz

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.

Yes. Selector conflicts are more subtle and therefore nastier than class name conflicts, and far more onerous to handle using prefixes. Given the choice, I’d much rather have namespaces for selectors than for classes.

(An advantage of only namespacing selectors is that you could use the most elegant namespace separator I’ve come across: a space. [object namespace method] is unambiguous, as long as you don’t also allow [namespace Class method]. I don’t expect this idea to win the day, though.)

As a practical example of a selector conflict, I once had an app crash on one user’s machine because it had a convenience method -[NSDictionary setDouble:forKey:], and an input manager hack defined a -setDouble:forKey: with conflicting semantics. I’ve heard of people being bitten by conflicts with methods introduced in superclasses in system updates, too.

Namespaces are a property of types, of which objects are just one form

Namespaces are a property of names, of which types are just one form.