Re: [RFC/Proposal] Cocoa.h header

[Alex Perez]

Fred Kiefer wrote:
[snip]
> Now that you asked me direectly, I have to get myself involved.

If it were up to me, I would have simply done the change. I chose to go 
the route of discussion, and you throw it back in my face and call it a 
 "non-discussion". Thanks, I'll remember that for next time. You've 
clearly demonstrated that my kind attempt at running anything by you 
will blow up in my face, so I should just simply not do it at all in the 
future, lest I be accused of starting "non-discussions" in the future.

> 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.

No, it's not contrary to my position. I was very careful to state that 
no applications *I* had ported needed any of the extra cruft in Cocoa.h. 
That statement is true no matter your experience. My experience is 
anecdotal, and yours is as well. But you should not make the poor 
assumption that because one app is poorly programmed and needs a #define 
or two that all Cocoa apps are like that, and that it deserves to be in 
Cocoa.h, which it does not.

> 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.

I will ask it again, would you put stuff having to do with NSString in 
the NSImage header? There's a right place, and a wrong place, and this 
extra stuff is clearly in the wrong place.

> 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.

Once again, this has nothing to do with *COCOA* per se.

> 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.

The ultimate proposal is to make Cocoa/Cocoa.h  be installed by default, 
which it is not now. This pre-discussion is about cleaning up the mess 
that has been made in said header file. It is worthy of a discussion, 
whether or not you think it's important.

As I said, if I had had my way I simply would have committed the fix 
with zero discussion. Since that's what you seem to want, I will simply 
do things such as this in the future.

Alex Perez