Re: [RFC/Proposal] Cocoa.h header

[Fred Kiefer]

Alex Perez 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 am all for keeping the *CONTENTS* of the file 
> in a more reasonable header. Our Cocoa.h needs to be functionally 
> equivalent to Apple's Cocoa.h, and right now it is not, there's a bunch 
> of extra cruft in there which dosen't belong *IN COCOA.H*. It belongs 
> somewhere more appropriate. As I said, the extra stuff in there is not 
> Cocoa compatibility stuff, it's Darwin/OS compatibility stuff, and it 
> should not be where it is currently.
>
> > Cocoa.h isn't used by gnustep programs, but by OSX programs; it make 
> > sense to add what's needed to help compile OSX programs on GNUstep in it.
> > I don't see much the point of putting a CocoaCompat.h -- it means that 
> > when you want to compile Cocoa program you will either need to include
> > CocoaCompat.h everywhere, or modify Cocoa.h to include it, which kinda 
> > defeat the point of having a Cocoa.h already installed..
>
>
> 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.
>
> 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.
>
> 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.

Now that you asked me direectly, I have to get myself involved.

So why did I create this file in the first place and why did I put in 
some extra stuff beside the to basic includes? This file is there to 
ease the process for porting badly programmed code from Cocoa to 
GNUstep. I think in GNUstep we all agree that you should rather include 
the classes you need in an application directly. Most Cocoa programmers 
take the easier road and rely on the Cocoa.h file and some automatic 
behaviour of their compiler environment. Now when I tried to port the 
much hyped application Books to GNUstep I found it much easier than 
patching all the source files to provide them with the environment they 
where used to, and so implemented Cocoa.h and put in the bits that where 
needed to get this code compiling.
So contrary to your position this was code needed to get Cocoa stuff to 
compile, just a different application.
You may be right on the point that the PI bit has nothing to do with 
Cocoa, rather with Darwin. I don't know, I would expect this to come 
from some sort of math.h file and I would prefer that files that need 
this constant import this header directly. But on Cocoa this is not 
needed so we will run into misbehaving files now and than. The question 
here is, what bad may come from conditionally defining this constant. If 
you have at least one example where this caused harm, I am open to talk 
about a removal.

The other bits are harder. Here we are faced with some extra stuff that 
comes from the Objective-C++ environment or rather upcoming C 
extensions. At the time this header was included we tried hard to 
prevent this extra definitions from causing harm. If we failed in that, 
I would at least want to see an example of what it is breaking.

To be honest, I don't understand your point at all. This file is only 
there to help people port their applications, which is not that common 
as task and I never heard from anybody complaining about specific 
problems here. You started the thread by claiming the extensions where 
bad, but in none of your mails you gave an evidence of this.

To follow up one of my recent mails, I would call this another 
non-discussion, something to distract GNUstep people from actually doing 
serious programming.

Fred