[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Richard Frith-Macdonald
Subject: Re: [RFA/base] GSObjCRuntime (Part 1: whitespace)
Date: Sat, 7 Jun 2003 06:55:11 +0100

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.)


   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.

reply via email to

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