Re: GNUstep Coding Standard Additions

[Richard Frith-Macdonald]

On 2005-04-30 08:05:03 +0100 Sheldon Gill <sheldon@westnet.net.au> wrote:

> Secondly, I'd like the docs to clearly state the source for 
> functions/methods 
> as OpenStep, MacOS (differentiate puma, jaguar, panther and tiger) or GS 
> (version).

The current documentation does that for Openstep/MacOS/GNUstep ... so 
extending the mechanism to differentiate between individual MacOS and 
GNUstep releases should be fairly simple ... it's just that it would take a 
lot of time to review methods to find which release each belongs to.  I 
guess we could extend the existing STRICT_OPENSTEP/STRICT_MACOS_X 
classification, but I think it might be better to add gnustep and openstep 
versioning as separate defines or as markup in the comments.  The advantage 
of using defines and using #ifdef/#ifndef/#if defined()  is that people can 
then easily check that their code does not use features which are not 
present in a particular version, however it's a bit more cumbersome to deal 
with.

> That said, doing so for everything is a big undertaking. To achieve this 
> someone will have to research the calls. I'd be happy to baseline now so 
> that 
> calls are OpenStep, MacOS (panther) or GS current.

We already have that ... are you saying you would review/check that all 
methods are in the correct grouping?   I think that would be great (there 
are almost certain to be some misclssifications) ... but if you are happy to 
review each method in the API, you could make the classification more finely 
grained (to release versions) if you like.

> Perhaps a new-comer would like to put up their hand to generate a reference 
> table marking all calls as one of the three?  Strikes me as a good way to 
> review the API and get familiar with the documentation. Could be a good 
> assignment for students, too. Anyone teach class?

I would prefer to continue with making sure that the defines in the header 
files mark the classification of each method accurately, and extend 
autogsdoc to generate such a table using that information... then the table 
can be kept in sync with the text of the documentation easily.

> Thirdly, I advocate moving GNUstep additions to Additions as far as 
> possible.

That's already underway... after all,  it's what 'Additions' was introduced 
for.