Quantcast

Adding namespaces to Objective-C

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Adding namespaces to Objective-C

Owen Shepherd
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/
[hidden email] (general) / [hidden email] (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.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Chris Lattner
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

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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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/
[hidden email] (general) / [hidden email] (university)


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

David Chisnall
In reply to this post by Owen Shepherd
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.

>>> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Blaine Garst
In reply to this post by Owen Shepherd
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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Owen Shepherd
In reply to this post by David Chisnall
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/
[hidden email] (general) / [hidden email] (university)


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Jean-Daniel Dupas-2
In reply to this post by Blaine Garst

Le 9 nov. 2010 à 23:35, Blaine Garst a écrit :

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

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





_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Chris Lattner
In reply to this post by Owen Shepherd

On Nov 9, 2010, at 3:50 PM, Owen Shepherd wrote:

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

FWIW, :: is not a token in ObjC.

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Jean-Daniel Dupas-2

Le 10 nov. 2010 à 01:51, Chris Lattner a écrit :

>
> On Nov 9, 2010, at 3:50 PM, Owen Shepherd wrote:
>
>>> 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.
>
> FWIW, :: is not a token in ObjC.

No, but it may be used in selector.

@selector(foo::::) 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





_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Douglas Gregor

On Nov 10, 2010, at 2:31 AM, Jean-Daniel Dupas wrote:

>
> Le 10 nov. 2010 à 01:51, Chris Lattner a écrit :
>
>>
>> On Nov 9, 2010, at 3:50 PM, Owen Shepherd wrote:
>>
>>>> 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.
>>
>> FWIW, :: is not a token in ObjC.
>
> No, but it may be used in selector.
>
> @selector(foo::::) is a valid selector. So, if namespace applies to selector too, you will have to figure a way to define qualified selector name.

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

        - Doug
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

David Chisnall-2
On 10 Nov 2010, at 16:03, Douglas Gregor wrote:

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


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


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Sean Hunt-2
In reply to this post by Douglas Gregor
On 10-11-10 11:03 AM, Douglas Gregor wrote:
> Or side-step the problem by using something other than "." in the equivalent of nested-name-specifiers.
>
> - Doug

How about the backslash?

Sean

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Chris Lattner

On Nov 10, 2010, at 8:52 AM, Sean Hunt wrote:

> On 10-11-10 11:03 AM, Douglas Gregor wrote:
>> Or side-step the problem by using something other than "." in the equivalent of nested-name-specifiers.
>>
>> - Doug
>
> How about the backslash?

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

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Ariel V Feinerman
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]; 

On Wed, Nov 10, 2010 at 6:59 PM, Chris Lattner <[hidden email]> wrote:

On Nov 10, 2010, at 8:52 AM, Sean Hunt wrote:

> On 10-11-10 11:03 AM, Douglas Gregor wrote:
>> Or side-step the problem by using something other than "." in the equivalent of nested-name-specifiers.
>>
>>      - Doug
>
> How about the backslash?

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

-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev



--
best regards
Ariel

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Owen Shepherd
On 10 Nov 2010, at 19:23, Ariel V Feinerman wrote:

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

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

-- Owen Shepherd
http://www.owenshepherd.net/
[hidden email] (general) / [hidden email] (university)


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Ariel V Feinerman
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?  


On Wed, Nov 10, 2010 at 9:52 PM, Owen Shepherd <[hidden email]> wrote:
On 10 Nov 2010, at 19:23, Ariel V Feinerman wrote:

> 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.
 
Namespaces give us the ability to have longer entity names, without the inconvenience this would normally cause.

-- Owen Shepherd
http://www.owenshepherd.net/
[hidden email] (general) / [hidden email] (university)




--
best regards
Ariel

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Owen Shepherd
On 11 Nov 2010, at 13:37, Ariel V Feinerman wrote:

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


On Wed, Nov 10, 2010 at 9:52 PM, Owen Shepherd <[hidden email]> wrote:
On 10 Nov 2010, at 19:23, Ariel V Feinerman wrote:

> 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/
[hidden email] (general) / [hidden email] (university)


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

jahanian
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

On Nov 11, 2010, at 8:34 AM, Owen Shepherd wrote:

On 11 Nov 2010, at 13:37, Ariel V Feinerman wrote:

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



_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Adding namespaces to Objective-C

Jens Ayton
In reply to this post by Owen Shepherd
On Nov 9, 2010, at 22:54, Owen Shepherd wrote:
>
>
> 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.


On Nov 10, 2010, at 00:50, Owen Shepherd wrote:
>
>
> 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.


On Nov 11, 2010, at 19:41, jahanian wrote:
>
> 1. Somehow c has survived 30+ years not needing namespaces. I am told that it is not on the table yet.

C (per se) doesn’t have dynamic name lookups.


--
Jens Ayton


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
12
Loading...