[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Coding Standard Additions
From: |
Alex Perez |
Subject: |
Re: GNUstep Coding Standard Additions |
Date: |
Sun, 08 May 2005 11:29:51 -0700 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
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
- Re: GNUstep Coding Standard Additions, (continued)
Re: GNUstep Coding Standard Additions, Sheldon Gill, 2005/05/01
Re: GNUstep Coding Standard Additions, Matt Rice, 2005/05/02
Re: GNUstep Coding Standard Additions, Adrian Robert, 2005/05/08
Re: GNUstep Coding Standard Additions,
Alex Perez <=