[cfe-dev] Adding namespaces to Objective-C

[Blaine Garst]

On Nov 9, 2010, at 1:54 PM, Owen Shepherd wrote:

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

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