discuss-gnustep
[Top][All Lists]
Advanced

[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:32:28 -0700
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Richard Frith-Macdonald wrote:
On 2005-05-08 14:17:27 +0100 Adrian Robert <arobert@cogsci.ucsd.edu> 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





reply via email to

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