Re: Introspection API

On Fri, 2005-02-25 at 12:10 -0500, Owen Taylor wrote:
>On Fri, 2005-02-25 at 11:08 -0500, John Ehresman wrote:
>> Matthias Clasen wrote:
>> > Is using libffi or something similar a problem ? 
>> I think we want to set things up so libffi could be easily used.  In 
>> other words, the information that libffi needs should be easily 
>> obtainable from the introspection api.  I'd also like not to have to 
>> wrap everything in GValue's if that can be avoided.  That said, we need 
>> to figure out how to package libffi for non-gcc compilers such as MS VC++.
>libffi in my memory has a pretty horrid interface, and I think there
>is some value in wrapping in something more GLibish. 
>GValue has significant performance problems,

  I was not aware of this, and it's an unpleasant surprise to find it
out, considering how GValue is used extensively in gtk+

> but perhaps we could just
>reuse it as a union and forget g_value_set_object() and friends for this
>usage. On the other hand, that might be confusing, so maybe a separate
>union structure (without the excessive space consumption of GValue)
>would make sense. 
>A wrapper also gives the ability to use something else internally -
>perhaps the XptCall stuff from Mozilla which certainly works with

  Right.  A XptCall/libffi kind of abstraction would be nice thing to
have in glib ;-)

> (I haven't really looked at the portability of libffi. The
>libgcj version is mixed up with GCC extensions, but that may not
>be fundamental to its operations.)
>My basic idea is that we'd provide something like:
> g_function_desc_invoke (GFunctionDesc    *desc, 
>                         const GArgument  *in_args,
>                         int               n_in_args,
>                         const GArgument  *out_args,
>                         int               n_out_args,
>                         GArgument        *return_value);
>Where GFunctionDesc is the API object for FunctionBlob. (I forget
>what it was called in Matthias's writeup.) You'd also want the reverse
>marshaling from C to GArgument.

  Right.  That looks like an interesting API to use by bindings.  Of
course, I don't really know what GArgument contains...

  It worries me that we already have PyObject<->GValue conversion code
in pygtk, but we'll have to create new conversion code for
PyObjec<->GArgument.  Are you sure GArgument is going to get us any
performance improvement at all?  If in doubt, I'd stick to GValue.


Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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