Re: [gtk-list] Re: Perl comments




Marius Vollmer <mvo@zagadka.ping.de> writes:

> But you seem to be thinking about passing values by reference so that
> the called function can modify it, right?
> 
> There is no support for that, but it might be worth adding that.  I
> think it would ba some kind of `meta' thing.  Not a new bunch of
> types, but as a new option for individual parameters.
> 
> Right now, there are the ad-hoc options `=' (for default values) and
> `null-ok' (for allowing NULL to be passed for a pointer).  Maybe we
> can add `by-ref'.

I would suggest instead adopting the IDL convention that parameters
can be "in" (default), "inout", or "out". Almost all such parameters
in functions and signal handlers are "out" not "inout" and this can
be used to advantage by language bindings. 

(e.g. ($x,$y) = $window->get_pointer() )

I suppose this might require a bit of addition to your type
specification to specify that some types get an extra reference
in C when passed "out" or "inout". (Perhaps that is already there)

> > I've got a slight bone to pick about GdkWindow: I'm of the opinion that
> > it's inappropriate to treat GdkPixmap as "a type of" GdkWindow (with the
> > result that GdkWindow is mentioned in gtk.defs). Since the various drawing
> > functions work on both GdkPixmap's and GdkWindow's, but the window
> > functions only work on GdkWindow, it seems to make much more sense to
> > treat GdkPixmap as the "base", with GdkWindow and GdkBitmap as inheriting
> > from GdkPixmap. (Yes, I realize this doesn't actually affect any code,
> > it's just a semantic change.)

Why not follow the way things set up in the C code typedef's and
consider all three subclasses of GdkDrawable? There's no reason to
assume the operations on either GdkPixmap or GdkWindow will always be
proper subset of the other, though it may work that way now.

Regards,
                                        Owen



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