On 2005-05-08 14:17:27 +0100 Adrian Robert <[EMAIL PROTECTED]> 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?
Correct ... deprecation and removal are different.
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:
Not sure about 'most' ... it's a currently a mix, but I don't know the proportions.
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?
Sounds OK ... I just think it's easier and more useful to organize by version, and straightforward to alphabetize within groups. Ordering by functional areras is very vague ... it's quite subjective what you consider to be a functional area (and we should try not to copy Apple as a general principle). I don't much care though.
#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.
I'm not sure about OPENSTEP versions, but we certainly discriminate between OpenStep (the specification, which we certainly do have online documentation for) and later APIs. There are certainly a few APIs that were added/removed between OpenStep and MacOS-X, so logically, we need to give them addition/removal versions other than 0.0 or 10.0
Personally, we could call them all 4.0 for all I care, but I imagine some people will want this to be correct.
None of these intermediate parts were ever officially released. Good documentation on when, exactly, something was added to Rhapsody, for instance, is completely lacking because of this, and I only think we should be dealing with *released* API changes, in which case 10.0 would be the first MacOS X version which contained the new API additions.
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 ... ?
I have no opinion on the exact naming we use ... I just suggested the first name that came into my head. If Alex is in a hurry to categorise, he oculd use any name and we could do a global search/replace to change it later.
For convenience. it should be a short but unique name which is fairly self-explanatory.
See my two previous e-mails on this issue.
Cheers, Alex Perez
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
