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

[Kenneth Albanowski <kjahds kjahds com>]

On 24 Aug 1997, Marius Vollmer wrote:

> 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.

OK, if so, this would be usable.

> 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.

I think that is overkill. When you are fighting the compiler that hard,
you probably want to shift to some other plan of attack. If we need
dynamic stubs that badly, we can always use some dynamic trampoline
package (one was recently released for Perl) to create the assembly at
runtime. The param[] mechanism is easier and more flexible in the long
run, except (ironically) at the C coding layer, where the marshalling
functions are needed.

> 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.

Hmm. That brings up an interesting issue: dealing with addition widgets.
There's no particular reason why the Perl code should only deal with Gtk
widgets, assuming other ones are written to the same standards. That would
mean additional enumeration types _would_ be nice. However, at this point,
I think the technical considerations make it too much of an issue.

Once we get to the point where _no_ C code is needed for the bindings
(where everything can go through the equivalent of setv) then transparent
support for new widgets is worth worrying about.

I'd say static enumerations would be best for now.

> 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.

Exactly what is needed.

> > 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.

That's another important issue: I don't want the Perl binding (or other
bindings) to spend five seconds on startup just sitting their in an orgy
of type queries. The more information that can be compiled in, the better. 

> 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.

I had to read the source code of many functions, true, but there are many
I haven't read, and many where it simply isn't easy to follow what exactly
is done with a parameter. In any case, it should _not_ be necessary to
read this stuff. Any decent documentation should sufficiently describe
this sort of thing. (And I don't mean that as an attack on anyone who
hasn't documented Gtk. Plenty of my own code isn't documented, and I'm not
proud of it.) 

> 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.

Great.:-)

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)