Re: [gtk-list] Re: A type system for high-level interfaces

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:
> 
> I'm afraid I don't have the time to fully comprehend this at the moment.
> From a quick glance, I strongly dislike all the dynamic business.

I think you can safely ignore the dynamic things.  The types can also
be used to describe the prototypes of the exported functions in a
completely static manner.  For example, gtk_button_new_with_label
could look like

    GtkButton gtk_button_new_with_label (string)

where "string" denotes the type called GTK_ARG_STRING in the proposal
and "GtkButton" is some subtype of GTK_ARG_OBJECT.  These description
are collected in a simple text file (or automatically snarfed from the
headers) where you can find them for automatic stub generation.  No
dynamic surprises.

But I still think that the dynamic types make things easier.  For
example, by exploiting the GtkArgs I can wrap all possible signal
handlers with one stub.

In fact, I'm thinking about writing one single but excessive generic
stub with libffi.  That stub would be able to call any function that
can be described in terms of the fundamental types just by giving it
the description at run-time.  You could link in a new widget at
run-time, read the descriptions of the exported functions and be ready
to go.  No stub generation and compilation.  It wouldn't be
particularily fast, but I doubt that you can spot the difference in
most cases.

> If enumeration constants are dynamic, for example, there is no oppurtunity
> at all for optimization of my Perl code which converts between strings and
> values, and Java code using type-safe enumeration objects would be equally
> impossible.

The list of literals of enumeration would probably not dynamic but the
new ones could pop up at any time.  If that is a problem, we can make
the set of enumerations exported by Gtk static.
 
> I'd say to keep all the types static, keep GTK_ARG_* almost exactly as it
> currently is, just add information on _which_ PTR or ENUM is intended, and
> leave it at that.

That's mostly what I want to do.  I don't propose that every int
carries a GTK_ARG_INTEGER tag with it.  But even for the static types,
we need stricter semantics that the C type system offers.  The
proposal intends to write them down, both for static use of the types
as well as the dynamic use.
 
> Some way to query what the enums contain would be handy, but there must be
> a way to do it such that the results will be static and usable even if
> embedded in subsequently compiled code.

Could be done I think.  I'll think some more and try to include it in
the proposal.

> Let me say that with the Perl code I've written, the absolute primary need
> to add robustness is simply information about what pointer parameters can
> be left NULL, and which cannot. 

That informations fits best into the unwritten Function Description
section, I think.

But -- unless I missing something -- writing rebust interface glue
requires being completely sure about the semantics of every little
function you want to wrap.  That usually requires reading the source
code and following the structures as they are passed around.  If you
have done that, my congratulations.

But I don't want to do that again, and when I do it, I don't want to
bury the results in cryptic code that only those understand who are
experts for the particular high-level language implementation.

Let me say it clearly: Gtk is already very close.  A large part of the
proposal states current practice.  The code that implements a large
part of the new things is shorter than the text of the proposal.  I
try hard to make the changes in a compatible way.  Only the GTK_ARG_*
constants have changed, but hopefully they aren't used much, because
everything is static anyway (as you say).

So please don't be afraid that I want to rewrite Gtk in Scheme or
something, far from it.

regards,
 Marius