On 10 Jun 2008, at 18:47, David Ayers wrote:
Richard Frith-Macdonald schrieb:
On 10 Jun 2008, at 15:28, David Ayers wrote:
Richard Frith-Macdonald schrieb:
Where we have methods which are GNUstep specific, they ought to
be in
If you have a better idea of how to go about this sort of thing
I'm very
willing to listen (even time consuming alternatives if you want to
volunteer to help out). I just don't want inaction to perpetuate
the
situation where people complain about lack of Apple compatibility.
Well I think the correct solution would be to use the version
macros to
hide the declarations in the Foundation/*h headers yet to re-declare
them unconditionally in a corresponding GNUstepAdditions/*.h header.
Perhaps I'm misunderstanding you ... but if you do that, then all
existing source code would fail to compile because declarations would
not be visible in the headers they are including now, but they
wouldnt
be including the new header they need.
I thought that this commit ...
http://svn.gna.org/viewcvs/gnustep/libs/base/trunk/Headers/Foundation/NSString.h?rev=26621&view=diff&r1=26621&r2=26620&p1=libs/base/trunk/Headers/Foundation/NSString.h&p2=/libs/base/trunk/Headers/Foundation/NSString.h
[http://tinyurl.com/3j3ysu]
... already breaks existing source code.
Thanks ... I made a typo and used the wrong macro name (fixed)
With GS_API_VERSION(GS_API_NONE, 011700) it should change the validity
of the methods in the GNUstep category from being always valid (no end
version), to being valid up to release 1.17.0
Since the current stable/unstable branches are 1.14.x and 1.15.x I
expect the next stable release to be 1.16.0 and the next unstable one
to be 1.17.0
This should mean that in the next stable release the methods are still
valid (usable), but autogsdoc marks them as deprecated, so people
shoudl see that if they look at the header files or the
documentation. No existing code should break.
But without providing an
alternative header to include. But in fact it seems that many of
those
declarations already exist in GSCategories.h. Sorry I should have
checked earlier. [Yet there are some declarations that are not
there...
not sure what should happen to them (maybe this is only true for
-immutableProxy]
So what I'm trying to say, is that we should insure that all those
methods are declared in GSCategories.h without the version macros.
And
maybe add a comment in the Foundation files to indicate where these
declarations have moved to.
I don't have time to decide where everything moves to in the next
day ... I doubt that I even have time to be sure I find all the
methods which are not in MacOS-X
I want current code to continue to compile and work with no
changes, but
to warn developers that things are going to change before the next
stable release.
Well if someone is using version macros now, they'll notice that the
declarations are hidden. If not, I suppose they can't get warned with
the current infrastructure. They'll notice once the declarations are
removed from the file which should probably still contain a general
comment about where declarations have been moved to.
autogsdoc parses the version macros to mark methods as deprecated when
it knows there is a removal date in the macro.
I think we could put more detailed documentation in the next bugfix
release.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev