Re: GNUstep Coding Standard Additions

[Adrian Robert]

> I think we are agreed that we want to categorise a method/class by
> the version where it was introduced, and the version where it was
> removed (NeXT/Apple have removed some things from their APIs)

This sounds like a good plan.
Just to be clear, deprecation does NOT count as removal, right?


> I would say the headers should be rearranged so that methods
> appear in order of the version in which they first appeared, and
> alphabetically within a version.  That way, adding/findng methods
> for a particular version range is trivial.

Currently most of the headers are not alphabetized, but have methods
organized by functional area.  E.g, in NSDate:

// Adding and getting intervals

- (id) addTimeInterval: (NSTimeInterval)seconds;
- (NSTimeInterval) timeIntervalSince1970;
- (NSTimeInterval) timeIntervalSinceDate: (NSDate*)otherDate;

...

// Comparing dates

- (NSComparisonResult) compare: (NSDate*)otherDate;
- (NSDate*) earlierDate: (NSDate*)otherDate;

I'm not wedded to this, but it's been around a long time and people
are used to it.  Rather than changing it everywhere, how about just
alphabetizing / sorting the additions and changes?


> #else if OSVERSION(4.2, 10.3)
> // Methods not in OpenStep, but present in OPENSTEP 4.2, then removed in 

How important is this tracking of OpenStep spec vs. OpenStep 4.2
(and 4.1, etc.)?  Do we even have online reference documentation for
this?  It seems like we have just been marking "OpenStep" in the API
so far without distinguishing versions and no complaints.

Also, I'm worried that "OSVERSION" will be confusing, particularly
when looking at code sitting on an Apple system.  How about
STEP_VERSION, API_VERSION, OS_API_VERSION, STEP_RELEASE, or ... ?