[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep Coding Standard Additions
From: |
Matt Rice |
Subject: |
Re: GNUstep Coding Standard Additions |
Date: |
Mon, 2 May 2005 15:49:15 -0700 (PDT) |
--- Richard Frith-Macdonald <richard@brainstorm.co.uk>
wrote:
> On 2005-04-30 08:05:03 +0100 Sheldon Gill
> <sheldon@westnet.net.au> wrote:
>
> >
> > Secondly, I'd like the docs to clearly state the
> source for
> > functions/methods
> > as OpenStep, MacOS (differentiate puma, jaguar,
> panther and tiger) or GS
> > (version).
>
> The current documentation does that for
> Openstep/MacOS/GNUstep ... so
> extending the mechanism to differentiate between
> individual MacOS and
> GNUstep releases should be fairly simple ... it's
> just that it would take a
> lot of time to review methods to find which release
> each belongs to. I
> guess we could extend the existing
> STRICT_OPENSTEP/STRICT_MACOS_X
> classification, but I think it might be better to
> add gnustep and openstep
> versioning as separate defines or as markup in the
> comments. The advantage
> of using defines and using #ifdef/#ifndef/#if
> defined() is that people can
> then easily check that their code does not use
> features which are not
> present in a particular version, however it's a bit
> more cumbersome to deal
> with.
>
> > That said, doing so for everything is a big
> undertaking. To achieve this
> > someone will have to research the calls. I'd be
> happy to baseline now so
> > that
> > calls are OpenStep, MacOS (panther) or GS current.
>
> We already have that ... are you saying you would
> review/check that all
> methods are in the correct grouping? I think that
> would be great (there
> are almost certain to be some misclssifications) ...
> but if you are happy to
> review each method in the API, you could make the
> classification more finely
> grained (to release versions) if you like.
>
here is something i hacked up a while ago, wasn't
going to release it as it's fairly gross code wise...
anyhow its a bunch of tools,
methodlists generates either a apple.plist or
gnustep.plist
which contains all the classes found at runtime and
their class and instance methods
merge merges an apple and gnustep.plist into one...
and the rest do some sort of html output from the
merged plist...
although it actually works a bit strange..
for example on one platform we have,
@interface objectone : NSObject
- (void) foo {}
@end
@implementation objecttwo : objectone
- (void) foo {}
@end
on the another platform we have:
@interface objectone : NSObject
- (void) foo {}
@end
@implementation objecttwo : objectone
@end
it'll mention that one platforms objectTwo implements
-foo and the other doesn't.
anyhow, if someone wants to use this or clean it up or
whatever maybe it'll help...
matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
methodlists-0.0.4.tar.gz
Description: methodlists-0.0.4.tar.gz