Re: [RFA/base] GSObjCRuntime (Part 2: NO_DEPRECATED macro)

[Richard Frith-Macdonald]

On Saturday, June 7, 2003, at 11:28  am, David Ayers wrote:

> > > - 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.
>
> Well this is one of my main objectives.  In +load we can obtain a 
> class via: GSClassFromName() (if the class was already loaded of 
> course.)

Good point.

> > 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.
>
> As long as we're dealing with single structs and pointers, I agree, we 
> don't need convinience methods.  That's why I wasn't suggesting 
> GSObjC*Method* functions.  I would like to have some indication of 
> whether a function is unsafe for +load or not.  I don't care whether 
> this is done through ObjC or some other prefix/suffix.  I also would 
> like most functionality (that seems sensible) available during +load.  
> But for "standard usage", when dealing with arrays and dictionaries 
> (like the GSObjCMakeClass and GSObjCAddClasses) c-arrays can get very 
> clumsy.  Personally I think that justifies moving the existing 
> implementation to being  "load safe" while providing the convience 
> functions for standard usage.  Right now, we just don't have safe 
> counterparts to be used during +load.  This is where I want to fill 
> the gap without losing ease of use.

OK ... but I don't think using the GS rather than GSObjC prefix is a 
good convention to indicate that ... there are a *lot* of GS prefixed 
functions elsewhere which are certainly not +load safe and have nothing 
to do with runtime manipulation.

I suggest using another prefix ...  perhaps GSC ?  Alternatively, don't 
bother with a naming convention, but explicitly state that the 
functions are +load safe in the documentation (ie in the comments 
before each of them).

Sorry for the *extremely* slow response ... I'm very busy at work at 
the moment, and haven't really had time to look at non-work-related 
email.