gnustep-dev
[Top][All Lists]
Advanced

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

Re: [RFC/Proposal] Cocoa.h header


From: Alex Perez
Subject: Re: [RFC/Proposal] Cocoa.h header
Date: Sun, 21 Nov 2004 13:24:42 -0800
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

Markus Hitter wrote:

Am 21.11.2004 um 02:51 schrieb Alex Perez:

Our Cocoa.h needs to be exactly the same as Apple's.


IMHO, it should result in the same behaviour as Apple's.

Yes, which does *NOT* include defining Pi and other such questionable things. Those things are for darwin compatibility, not cocoa, and I've yet to run across a cocoa app that needed them when I was porting stuff. So I've got loads of anecdotal evidence that it's not necessary. I think the potential for it to cause problems is greater than the potential benefit for the one or two apps that might need these #defines.

Right now, there's other darwin-compatibility stuff in there which should be elsewhere.

Where's the enhancement?
See http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/Cocoa/Cocoa.h?rev=1.1&content-type=text/vnd.viewcvs-markup


I propose that stuff be moved to Headers/Cocoa/CocoaCompat.h or something similar. Cocoa.h will not #import this file by default, it will be like most of the other compatibility headers which are distributed with GNUstep; You will need to know that you need to import it explicitly.


Which makes writing portable code again a little more complex. And adds a few lines of identical code to each source file.

As I said, I've yet to come across an OS X app which I was porting which needed any of these extras. Since the number of apps that need these extra things is low, they either be in a separate header file or removed completely.

One step back, IMHO. Better work on including the other compatibility headers automatically, depending on the situation, as well.

I respectfully disagree. You are operating under the assumption that these defines are necessary to port apps, when nothing could be further from the truth 99% of the time. As I said earlier, the potential downsides (which I outlined above) outweigh any miniscule benefits which may exist.

Cheres,
Alex Perez





reply via email to

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