Re: GtkType stuff

[Marius Vollmer <mvo zagadka ping de>]

Tim Janik <timj@gtk.org> writes:

> > 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.
> 
> but this is independant of the existing argument system.

Yes.
 
> erm, this has nothing to do with the GtkArg structure. GtkArgs are
> used for signals and the argument system. as you stated above, the
> information is needed on linkage time and does not interfere with
> the dynamic type stuff.  so why would you want to have information
> like that in GtkArg?

GtkArgs are used to pass values to signal handlers.  Thus, as of now,
signal handlers can only have signatures that are expressable with the
current GtkArg structure.  Thus, there is no signal handler that has
arguments with modes that are anything but "in".  Because the GtkArg
structure can not express other modes.

But what when signal handlers start wanting to have outward arguments?
Right now, the complete information about arguments is carried inside
an array of GtkArg structures, and I find it natural to retain that.
So I'd like to attach a `mode' indication to the passed values, just
like now the type is attached to them.  For this run-time use of modes
that are attached to values (dynamic modes, if you are so inclined, to
go with dynamic types), I find the `optimization hint' interpretion be
better suited.  Maybe we should ditch the name `mode' altogether and
only talk about `flow hints' or something.  These flow hints would
only take effect for composite types, values of all the other types
are only allowed to flow `in'.

Since there are no composite types now, no existing code needs to
change and we don't have the problem how to implement outward flow for
the existing types.

> also, i'd like to keep the GtkArg structure as small as possible, since
> gui builders and eventually some langueage bindings make extensive use
> of it.

Can we remove the `name' field?

I think the most prominent user of GtkArg structures right now is the
signal system.  I've shortly thought about avoiding this by putting
some assembler magic into place that extents the va_args mechanism so
that you can call a function with an va_list.  Along the lines of what
libffi or ffcall provide, but more specialized.


[ Declarations in header files ]

> i'd guess that some simple rules would basically do the trick for the
> in/out stuff, e.g. return values are always out, with char* being
> considered as dynamically allocated by default. similar rules would apply
> for the function arguments, e.g. "int", "float" and "char*" are considered
> `in' parameters and "int*", "float*" and "char**" are considered `out'.

This can work to get a useful approximation to the initial definitions
into the header files.  But I don't think we should use this magic
routinely.

That is, as a one shot tool to save us (ok, me) a large amount of work
up front, this would be very useful.  But I *don't* want to have a
situation where someone innocently puts a funtion prototype into a
header file, and then it gets magically converted into a *.defs
definition which is wrong, without anybody ever noticing.

> (define-func gtk_widget_get_name
>   (string (mode dynamic-alloc))
>   ((GtkWidget *widget)))

There should be no `*' in the definition.
 
> > > 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.
> 
> i don't think this scheme is too tricky, and it has been sufficient for
> at least the enums ;)

Ahh, the enums!  Piece'o'cake! :-)

> i think we can get close to the matching-rate for enums with the function
> definitions as well, if we come up with smart defaults for the .defs
> generator.

I think the same, but I don't want to stop at being close.  I want to
get there.  You know, Windows apps aren't crappy because they run on
Windows.  They are crappy because they are crappy.  Just not writing
for Windows can't save you from writing crappy apps. ;-)

> > When they don't know how to do it, then their functions shouldn't be
> > described in gtk.defs.

I want to make clear that I don't blame anyone for not knowing how to
do it.

Well, many years ago, when it came to confessing on which side of the
C/Pascal medal one was, I was a strong C believer.  If I would've
known about Usenet flamewars then, you could've probably hear me say
some very offensive things about P.  But I think I've gotten over
this.  There is this saying that Pascal makes you beg "please, please,
let me do this, I know what`m doing.", but it wont let you.  C makes
you say: "I'm sorry, I didn't meant to...".  There's got to be a
middle way.  I want to try to offer this middle way with the type
system.