On Thu, 2004-02-05 at 17:42, James Henstridge wrote: > On 06/02/04 02:46, Bob Smith wrote: > > >Exactly. This was what I was talking about when I suggested making > >GObject's self describing. a GObject could then be introspected by > >CORBA, DBus, Python, Whatever to allow the scripting functionality > >easily. I think GObject's properties are self describing currently but > >methods are not. Anyone know what else would need to be described to > >make this possible? > > > > > The ORBit2 IInterface IDL would be worth looking at for this kind of > thing. You basically want: > > * get the type of an object (we already have this with > G_OBJECT_GET_CLASS() or G_OBJECT_TYPE()). > * A way to find all base classes of a particular class (also already > available). > * A way to get a list of the methods of a class. > * For each method on the class: > o The return type > o List of argument names (you might consider this optional) > o List of argument types > o Whether each argument is in, out or inout. > * Require that all function arguments and return values can be > represented by the type system (this requires a fair bit of > work). This might involve extending the type system. Hmm... This would be a lot of work to program in all this information manually. I believe the GTK# project has a program that analyzes C files and produces an XML description of the GObjects... If they do, maybe it could be modified or an XSLT document be created to convert that information to a form that can be automatically linked into a library/program. > * Some way to invoke a method on an instance programatically. > > The last one is probably most difficult. The two ways to solve it are > to generate marshalling code (similar to what we do for signals), or use > something like libffi to construct the function calls (probably making > use of the interface information to help construct the call). > Yeah. Mono seems to be doing fairly well doing this sort of thing. Maybe their team can provide a good solution to the problem. > For GTK, we haven't really had to worry about this because C can already > call C functions quite easily :) For CORBA, they needed to deal with > this from the start, since they needed to be able to convert invocations > from the network into function calls. > > Note that most of the language bindings for dynamic languages actually > implement most of this already. Unfortunately, the format they expose > all the class information in is "Python classes" or "Perl classes", and > method calls are done using the "Python method call interface" or "Perl > method call interface" :) This isn't very helpful if you are trying to > use the information from a language other than the one the binding is > for ... > Know how COM on Python works? Does it create proxy Python objects? We could do the same thing... > James. -- Bob Smith <bob thestuff net>
Attachment:
signature.asc
Description: This is a digitally signed message part