Re: [gtk-list] Re: Perl comments



Kenneth Albanowski <kjahds@kjahds.com> writes:
>
> On 20 Oct 1997, Marius Vollmer wrote:
> 
> > But you seem to be thinking about passing values by reference so that
> > the called function can modify it, right?
> 
> Values are already passed by reference for several signals, as well as the
> return value from signals. But this isn't done consistently, and can be
> baffling. (Consider the return value from a timeout, which is called
> GTK_TYPE_BOOL, but is really stored as GTK_RETLOC_BOOL(arg).) Without
> completely consistency, there is no way for my Perl marshalling functions
> to deal automatically with all available types.

I think return values are consistently handled.  The last element of
the GtkArg array (which is not included in the argument count) carries
a pointer to a location for the return value.  You can access this
location with the GTK_RETLOC macros.  There is a GTK_RETLOC for every
fundamental GTK_TYPE.  I think all marshalling works this way.  When
there are exceptions, they need to be assimilated.  Resistance is
futile.
 
> The timeout_add_interp and idle_add_interp go some direction in unifying
> everything, but more work is needed. Ideally, I would love to see a single
> style of marshalling function (currently the signal marshaller has a
> different signature from the idle/timeout marshaller),

Hmm, really?  They both are GtkCallbackMarshallers, no?

> You mean in your working .defs file? This actually doesn't help me as
> much, because the marshalling functions must be dynamic.

Yes, you are right.  We need to enhance the GtkArg mechanism as well.
Maybe a new GtkArg field would do it.

    enum GtkArgMode {
       GTK_ARG_IN,
       GTK_ARG_OUT,
       GTK_ARG_INOUT
    };

    struct GtkArg {
      ...
      GtkArgMode mode;
      ...
    };

And then change the GTK_RETLOC macros to GTK_VALLOC and rule that
whenever the mode is out or inout the value must be accessed by

    *GTK_VALLOC_INT(arg)

etc.

Is this still easier than using ILU?


> However, I have noticed one general fault: to make use of a name like
> GtkFooBar, in some cases it must be transformed to gtk_foo_bar, and
> GTK_FOO_BAR, and perhaps a few other variants. Currently this seems safe
> enough to do, but it strikes me that this is not a very reliable
> mechanism, and that not all languages may be as adept as Perl in dealing
> with these transformations.

Hmm, yes, the name business is quite a hack.  What do you propose?



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