Re: GtkType stuff

[Marius Vollmer <mvo zagadka ping de>]

Ok, on with it.

Tim Janik <timj@gtk.org> writes:

> > * Modes
> > 
> > We need to deal with `pass by reference'.  I'd like to add modes to
> > argument specifications (and also to values when they are used as
> > arguments in the signal system (I'think I'm a bit confusing here)).
> > Mode `in' is what we have now, modes `inout' and `out' are the obvious
> > extensions.  I want to allow outward modes only for composite types so
> > that the calling conventions are completely unaffected by the mode of
> > an argument.  The typical case of
> > 
> >     void foo (int *x_ret);
> > 
> > would have to be declared as a function taking a vector of fixed
> > length 1 with content type "int" and mode `out' (or `inout').
> 
> again, i'm not sure on how you intend to fit this into the actual
> type system. at least for the GtkArg functions, the in/out behaviour
> it pretty much defined.

To what functions are you referring exactly?  I assume gtk_object_get,
get_object_set and GTK_ARG_READABLE, GTK_ARG_WRITABLE, etc.

If I understand them correctly, they refer to the properties of the
`object arguments'.  Whether they can be read, written, and other
stuff.  Right?

This is similar too but not the same as what I want to have modes for.
This is more of an issue for the static side of the type system.  We
need to describe function signatures, and pass by reference is a
useful technique that needs to be covered by these descriptions.

This is somewhat independent from the dynamic side of the type system.
The dynamic side should mirror the static side as close as possible,
but it need not include everything.

So the first thing is to have modes for the formal arguments of
functions.  An example: the function

    void foo (int x);

would be described within the static side of the Gtk type system as
(in gtk.defs notation):

    (define-func foo
      none
      ((int x (mode in))))

where `(mode in)' is the default and can be left out.  Mode "in" means
that the function foo is not allowed to change the value of x.  Mode
"out" means that it is allowed to do so, but it shouldn't expect any
useful initial value.  Mode "inout" is the logical combination.

Now, one might want this description

    (define-func foo
      none
      ((int x (mode out))))

to correspond to

    void foo (int *x);

But I don't want to make the mapping between Gtk type system types and
C types dependent on the mode.  Rather, a mode other than "in" is only
meaningful for composite type because those types represent values
that can be mutated.  So the right description would be

    (define-func foo
      none
      (((vec int 1) x (mode out))))

Another way to see these modes that might make more sense: they are
just hints for potential optimizations.  Think about a binding that
has to explicitely convert between its own representation of vectors
and the C representation.  To be right, it would have to convert from
its representation to the C one when calling a function, and would
have to convert back when the function has returned.  The mode hint
allows us to drop one of these conversions (which might be costly
indeed).

Now, I'm not too sure how to get this into the run-time side of the
type system.  Maybe a new field in GtkArg.

An open issue is what to do about aliasing.  If we have a funtion with
two outward arguments, and specify the same composite value for both
of them, what is the language binding required to do in this case?

[ Declarations in header files ]

> we had that for enums and flags already, some time ago, and it didn't 
> find the widest acceptance for most people, that's why owen jumped
> in and created the above mentioned perl script.

I see.  But I don't particularily like the guessing of the prefix.  I
have to admit that I don't fully understand what's going on in the
Perl script, so I have to look closer.

> a bunch of the gtk functions should really be easy to convert into an
> appriopriate .defs file format, using a smart prototype parser.

My stance on this is that it is not possible to do this reliably.
That's actually the point of this while gtk.defs business: to provide
*more* information than is evident from the header files.  Just
guessing, well a "char*" is like a "string" is not good enough.
That's also where "char" breaks down: what's it, a character or a
small integer?

> the results could then be adapted for some functions that need special
> casing.

Hmm, too tricky, in my view.  The default should be safe.  So when you
do not specifically declare a function to be fit for gtk.defs it
shouldn't be included, IMO.

> also, not all widget writers are aware of the usage and means of the
> .defs file formats, requiring them to put GTK_DEFFUNC() macros into
> the header would but a burden on them that is, imho, unjustified.

When they don't know how to do it, then their functions shouldn't be
described in gtk.defs.  Yes, you actually have to take a bunch of
maybe non-obvious things into consideration when writing the *.defs
stuff, and it is a burden.  But I dont't think that convenience is a
good enough reason to be sloppy here.  The *.defs file must be precise
and it must be right.  That's its sole purpose.