discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sync.m


From: Richard Frith-Macdonald
Subject: Re: sync.m
Date: Mon, 1 Mar 2010 06:07:21 +0000

On 1 Mar 2010, at 00:12, Riccardo Mottola wrote:


> It is not that I removed and changed stuff randomly, I just changed it where 
> I needed it to get things to compile.

Yes, I think we all understand that.

> So I'd like the compatibility library to continue to compile. I'm perfectly 
> fine to use the old libobjc on the systems with old or weird compilers.

Using the old libobjc is not currently a problem, the problem is using the old 
API (or more accurately, having to use multiple runtime APIs)... I'm not really 
happy to continue using the old API for two reasons:
To keep the code maintainable, we want to use a single API rather than using 
#ifdef to select alternative code fragments for different APIs.
To maximise portability between GNUstep/OSX, we need that single API to be the 
one Apple use (we've tried using our own, and people weren't happy with that 
choice).
The compatibility code should let us use the single API we want, with both old 
and new runtimes, so I'm very grateful that Etoile provided it.

> As long of course as core itself doesn't require libobjc-2 feature (which I 
> hope will be never, but that's tough to say).

That depends what you mean by 'require' ... some of Apples new OSX APIs cannot 
be implemented without ObjC2 features because they are built in to the API ... 
so to implement those features we will *have* to use ObjC2. However, for the 
forseeable future we are going to want to have GNUstep be able to build without 
ObjC2 on platforms where it is not available (and just leave the bits which 
require Objc2 unimplemented in those cases).

> Things used to work well enough even on gcc 2.95 to have the whole gnustep 
> core, gworkspace, systemprefrences, projectcenter, gorm and all of GAP 
> compiling and working. That is all I ask, I do not expect to use Obj-c2 
> programs or etoile there. But breaking them gratuitously is stupid.

Nobody is breaking things gratuitously.  The c99isms slip in to code simply 
because all modern compilers support them, and don't warn you that older 
compilers won't.  Most people use them habitually (locality of declaration of 
variables is particularly good for code readability for instance) and simply 
won't notice that they have used them.

Asking people to upgrade and use more modern compilers won't break any existing 
applications (old code will continue to compile), but would mean that we 
wouldn't have to keep trying to remember not to use c99 features, we wouldn't 
need to waste the time of people like you and me 'fixing' code which slips 
through into svn using them, and arguably we could write slightly better code. 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]