On Mon, 13 Sep 2010 12:58:20 +0100, David Chisnall <sqdqdq...@qsdqsdqd.org> wrote: > 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
In the same time do you have an idea of how many people are interested in gnustep ? I would be very curious to know it. DO you some some fugures ? _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
