Re: PATCH: Bug with Patch for libobjc (fwd)

[Nicola Pero <nicola at brainstorm dot co dot uk>]

problem with mail bounced back the original one - reposting

---------- Forwarded message ----------
Date: Mon, 10 Dec 2001 12:40:10 +0000 (GMT)
From: Nicola Pero <nicola@brainstorm.co.uk>
To: Jay McCarthy <jay@kenyamountain.com>
Cc: Stan Shebs <shebs@apple.com>, ovidiu@cup.hp.com, bug-gcc@gcc.gnu.org
Subject: Re: PATCH: Bug with Patch for libobjc


Hi - good point - but exposing the declaration of class_add_method_list
would not make it usable anyway, because the fact is that
class_add_method_list is to be called when the objc_runtime mutex has
already been locked _ and the runtime mutex is private - so you have to
trick with private code anyway in order to use it.

remember that if you really want to touch runtime internals, you can still
declare the class_add_method_list function yourself, and the
__objc_runtime_mutex yourself, declaring them as `extern', and then you
can use them - at your risk (if the libobjc internals change it won't work
any longer).

But - yes - I strongly agree there should be a public version of
class_add_method_list, which automatically locks/unlocks the runtime for
you.

I also think it would be nice to have a function to programmatically
create a new class and register it with the runtime, and to have a couple
of functions to allocate a method list (without having to know how the
method list is laid out internally) and to add a method to a method list
(again without having to know about the method list internals).

Variants of these functions are already to be found in the gnustep guile
interface, in the gnustep java interface, in the gnustep ruby interface,
and possibly in other code outside gnustep as well.  I really think it
would be nice to factor out this code and to put it where it belongs, in
the objc runtime library.  this would leave the interfaces cleaner, with
less needs to acces runtime internals, and would make writing new
interfaces easier.

not to say that - if apple people implement corresponding functions for
the next runtime, it might make porting these interfaces to the other
runtime easier.

anyway - I'll post patches to gcc for this stuff when I got time to get
back to this - for now you can just use the same ugly hack that JIGS and
the other Objc interfaces uses - 

void ObjcUtilities_register_method_list (Class class, MethodList *ml)
{
  objc_EXPORT void class_add_method_list (Class class, MethodList_t list);
  objc_EXPORT objc_mutex_t __objc_runtime_mutex;
  
  objc_mutex_lock (__objc_runtime_mutex);
  class_add_method_list (class, ml);
  objc_mutex_unlock (__objc_runtime_mutex);
}

we definitely want to rename this function and put it in the runtime
because it's too silly to have to do this.  I'll post a patch for this to
gcc later on.

> Sorry,
> Because it was in the directory with the rest of the headers which are 
> public I presumed it was.
> It defines a function class_add_method_list - which is equivalent to a 
> NeXT runtime call classAddMethods which WAS public (as was the entire 
> objc/objc-runtime.h header). Is that to say that this functions should 
> not/can not be used? I can just as easily go and rip the code for that 
> function from libobjc to get this call but that seemed unnecessary.
> 
> Thank you the explanation.
> Jay
> 
> On Friday, December 7, 2001, at 06:32  AM, Nicola Pero wrote:
> 
> > Hi
> >
> > thanks - runtime.h is a private header file of libobjc - should not be
> > used by external/user code - this is why is not installed.
> >
> >
> >> A header file (runtime.h) is not being installed in the
> >> PREFIX/lib/gcc-lib/TARGET/VERSION/include/objc directory.
> >
> >
> >
> ------
> Jay McCarthy
> 
> aim / irc \ work aim
> rasarasda / feelicks \ emontapartimejob
> http://www.brunswickrecords.org/~jay/
>