Re: GNUstep Coding Standard Additions

[Alex Perez]

Adrian Robert wrote:
> > 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?

No, deprecation counts as deprecation, and should be noted as such. :)

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

Well, as I just wrote in another e-mail, it's not something I am willing 
to do, so unless someone else is going to, it ain't gonna happen ;-)

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

Completely not important. It might have been 10 years ago. I will not be 
tracking this either, as stated in the other e-mail.

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

Nor will I be implementing the macros (yet), so you guys can discuss 
this into the ground while I go get some documentation work done :) My 
personal opinion on the matter is that the OSVERSION macro is utterly 
unnecessary, and should absolutely not be added.

Cheers,
Alex Perez