Re: [RFC/Proposal] Cocoa.h header

[Nicolas Roard]

On 2004-11-21 21:31:09 +0000 Alex Perez <address@hidden> wrote:

> Nicolas Roard wrote:
>> 
>> Le 21 nov. 04, à 01:51, Alex Perez a écrit :
>> 
>>> Currently, GNUstep-GUI has a file in Headers/Cocoa/Cocoa.h which is not 
>>> installed by default. I would like to change that, because there's no 
>>> reason for it not to be installed, and I have a use/need for it. However, 
>>> the header is not a direct analog to the Apple's Cocoa.h. This is bad. I 
>>> propose the following:
>>> 
>>> Our Cocoa.h needs to be exactly the same as Apple's. All Apple's does is 
>>> #import <Foundation/Foundation.h> and #import <AppKit/AppKit.h> and 
>>> *THAT'S IT*. Right now, there's other darwin-compatibility stuff in there 
>>> which should be elsewhere. 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.
>>> 
>>> Both of these files would then be installed when make install is run for 
>>> -GUI.
>>> 
>>> Please, contribute your feedback. If you are against such an action, 
>>> please explain why and what you propose instead.
>> 
>> 
>> Installing Cocoa.h by default is probably a good thing (possibly not 
>> installable by a configure flag), but I don't understand why we shouldn't 
>> put the compatibility stuff in it ?
> 
> Because I've yet to see an OS X app yet that needed any of them to actually 
> work/compile.

I'm sorry, but I encounteered quite a few OSX apps that wants to use 
bool,false, true,
instead of BOOL, NO, YES. It seems a quite common use.

> Would you put stuff to do with NSTableView in an NSObject header? No, because 
> it doesn't belong there. There's a more appropriate place for it, and that's 
> where it should be. I reiterate, I am in no way opposed to the "cocoa" (sic) 
> compatibility stuff, but I *AM* opposed to it being in Cocoa.h.

WHY ?
gosh, there is only two things in that Cocoa.h : a definition of boolean and a 
M_PI.
Is it so terrible ?
 
> As I said in my previous mail, I've yet to come across a cocoa app which 
> needs any of the extra cruft in our Cocoa.h (I use my own which ONLY includes 
> AppKit.h and Foundation.h and nothing else, just as Apple's does) and as such 
> I do not think it belongs there, because the potential for the extra stuff to 
> cause problems is greater than the potential benefit.

And *I* encounteered a few apps that use true/false. So, "as such I think
it belongs there, because the potential for the extra stuff to cause problems is
lesser than the potential benefit".

I don't know about M_PI, but it doesn't seem very annoying to have it as well.
 
> For the record, last I checked, Alexander Malmberg agreed that Cocoa.h should 
> not have all this extra cruft as well. Alex, I'd appreciate it if you'd weigh 
> in on this matter here. The same goes for you, Fred, since you're the one who 
> put the stuff into the header in the first place.

I *really* don't understand your point. This conversation starts to look 
senseless.
Cocoa.h isn't a GNUstep header -- it's only logical function is here to help 
Cocoa
apps to be compiled on GNUstep with as less modifications as possible.
In that view, it's only logical to include as well some useful tidbits like the 
booleans,
because some Cocoa apps use them (even if they shouldn't). 

If it's not its function, we could as well remove Cocoa.h and just ask people 
that want to compile their Cocoa apps to just replace #import <Cocoa/Cocoa.h> 
by import of AppKit and Foundation.

If Cocoa.h was some kind of useful thing for GNUstep, it could make sense to try
to have a "clean" file. As it's only role is to ease porting, I don't see your 
point.

I can only agree with Fred here that it's a completely useless discussion.

-- 
Nicolas Roard