discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep Coding Standard Additions


From: Richard Frith-Macdonald
Subject: Re: GNUstep Coding Standard Additions
Date: Mon, 02 May 2005 07:54:58 +0100

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.





reply via email to

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