Re: Interesting discussion on gcc about objc

[David Chisnall]

On 13 Sep 2010, at 10:38, Vincent Richomme wrote:

> Seach : Merging Apple's Objective-C 2.0 compiler changes
> http://gcc.gnu.org/ml/gcc/2010-09/threads.html#00151

I think you and I have different definitions of 'interesting' - a load of posts 
by people who aren't lawyers discussing legal matters (particularly 
incompetently, since none of them bothered to cite the SFLC's statement on 
precisely the matter that they were discussing), and two posts of vague 
technical interest.

Nicola, I'll reply here since you read this list, and you can forward anything 
of interest to the gcc discussion:

This was about the only reply to your message to say anything of interest.

> GNU ObjC
> has so few users that it seems hardly worth the effort to upgrade the
> GNU ObjC front end to ObjC 2.0. And there are other issues:

Translation: The GNU project doesn't care about GNUstep.

> * What standard is going to be implemented? ObjC 2.0 is not even a
> documented language standard, so you probably end up with something
> that is incompatible with Apple ObjC anyway. Without a documented
> standard, the only "standard" is the Apple compiler, which you cannot
> look at without risking copyright problems. The latest state of ObjC
> 2.0 on apple branches on gcc.gnu.org may not be the "current" ObjC
> 2.0.

There is an ObjC 2 language description.  It is not a formal specification, but 
it's better than nothing, and both Apple GCC and Clang follow it.

> * How do ObjC 2.0 and ObjC++ interact?

Badly.  But no worse than ObjC++ in general (which is unsupported on gcc 
anyway, and not included with the default build).  In particular, the dot 
syntax for properties makes parsing ObjC++ painful.

> Even now, there is already the
> problem of the two exception handling models, and AFAIU that will only
> get more complicated with ObjC 2.0.

This is no issue at all.  The GNU runtime solved this about five years before 
Apple introduced zero-cost exceptions, although it's a buggy implementation.  
libobjc2 solves it properly and allows mixing of ObjC and C++ exceptions 
properly, and even allows you to catch C++ exceptions boxed as ObjC objects (in 
theory - in practice LLVM contains some bugs that make this break - hopefully 
they'll be fixed by someone eventually).

> * What does it mean for existing GNU ObjC users to make the headers
> and runtime compatible with NEXTnow? These changes break source
> compatibility, I guess, and if that is indeed the case then the
> question is whether that is acceptable or not.

We already have an MIT-licensed runtime in svn that implements the ObjC 2 
runtime features and works with GNUstep, so this isn't a problem.

A much bigger issue is that the Apple patches are largely useless.  They are 
quite specific to the Apple runtime.  NeXT/Apple never merged the original GNU 
runtime support stuff into their branch, so the FSF's branch has a load of 
#ifdef crap that isn't present in Apple's branch and so merging from Apple's 
branch is nontrivial.  

You might be able to import the declared properties stuff, since we implement 
the same runtime functions as the Apple runtime.  You won't be able to import 
any of the newer stuff for the nonfragile ABI, because this is implemented 
differently in libobjc2 (since we can't rely on being able to rewrite the 
loader on every platform we support).  

If anyone in GCC cares (which I very much doubt), the libobjc2 non-fragile ABI 
is actually documented (unlike the old GNU libobjc ABI), so it should be 
relatively easy to support.  

I'm going to quote this again, because it pretty much sums up GCC's attitude to 
GNUstep since before I joined the project:

> GNU ObjC has so few users that it seems hardly worth the effort 

I'd love to see GCC provide a modern ObjC implementation, but it doesn't look 
particularly promising.

David