Re: [RFA/base] GSObjCRuntime (Part 1: whitespace)

[Richard Frith-Macdonald]

On Thursday, June 5, 2003, at 05:37  pm, David Ayers wrote:
> Here is the plan I have for GSObjCRuntime...
>
> I have the following goals:
> - better conformance to GNU coding standards.
> - grouping of depricateded functions and wrapping them in a #ifndef 
> NO_DEPRECATED macro
> - additional functions / typedefs for runtime manipulations of methods:
>    typedef struct objc_method *GSMethod;
>        (Needed because GNU and NeXT/Apple runtime define Method(_t) 
> differently and using the the struct is rather clumsy.)

Good.

>    GSMethod GSGetInstanceMethod(Class class, SEL sel);
>    GSMethod GSGetClassMethod(Class class, SEL sel);
>       (These functions search up the class hierarchy)
>    GSMethod GSGetInstanceMethodInClass(Class class, SEL sel);
>    GSMethod GSGetClassMethodInClass(Class class, SEL sel);
>       (These functions only search the given class an not its 
> superclasses)

Sounds OK, but the distinction between the two types does not seem 
clear from the names.
Perhaps something like 'NotInherited' rather than 'InClass' ? ... I'm 
not sure whether that's any better though.
Also, they break the convention that all runtime manipulation functions 
begin with GSObjC

> This is what I need for the following patches on gdl2.  I would later 
> propose to follow up with:
> - similar functions for accessing runtime instance variable 
> information:
>    typedef struct objc_ivar *GSIVar
>
>    GSIVar *GSGetInstanceDefinition(Class class, const char *name);
>    GSIVar *GSObjCGetInstanceDefinition(Class class, NSString *name);
>    GSIVar *GSGetInstanceDefinitionInClass(Class class, const char 
> *name);
>    GSIVar *GSObjCGetInstanceDefinitionInClass(Class class, NSString 
> *name);

Getting an ivar definition in a struct is nice.
I'm not sure about the need for the distinction between an ivar defined 
in the class and one defined in a superclass.  I don't think there is 
ever any reason to treat the two separately.  Is the idea simply to 
parallel the instance method functions?  If so, I think I'd prefer just 
to omit the 'InClass' version.

> - splitting some GSObjC* and GS* functions, where the GSObjC* 
> functions are convience functions using full fledged objects and 
> messaging and thier GS* counterparts are the actual implementations 
> interfaceing the runtime structures/functions so that they can be 
> "safely" used during +load.  Candidates are:

I don't think this is worthwhile  (not for use during +load anyway ... 
as the use of any of these is likely to at least require you to pass a 
Class as an argument, and to obtain a class you almost always have to 
do something like [foo class] ... which will usually cause trouble in 
+load), or desirable.

We should stick with the current convention that *ALL*  the ObjC 
runtime manipulation functions should have the GSObjC prefix rather 
than attempting to drop the 'ObjC' part from some. Also, I prefer to 
keep the API small rather than adding a lot of convenience functions.  
I think the challenge is to pick the best compromise of convenience and 
efficiency in the arguments passed to the functions.


> I'll also try to supply documentation for everything I touch, that 
> doesn't have documentation yet.  I generally have no personal 
> preference of whether documentation is in the header or the source 
> file.  But I don't really like it, if it's not used consistently in 
> one or the other for a source/header pair.  In the case of 
> GSObjCRuntime, many functions are static inlined in the header, so I 
> would also like to move the documtation of all functions to the 
> header, if you don't mind.
>
> Please let me know what you think of all of this.  (That goes for 
> anyone interested.)  I'm especially open to any suggestions for a 
> better naming scheme.
>
> To start things off, I've attached a pure whitespace patch (GNU coding 
> standards and readability) for the first step.  OK to commit?

Looks fine to me.