Re: [gtk-list] A type system for high-level interfaces
- From: Kenneth Albanowski <kjahds kjahds com>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] A type system for high-level interfaces
- Date: Sun, 24 Aug 1997 15:10:44 -0400 (EDT)
On 24 Aug 1997, Marius Vollmer wrote:
> I'd like to propose the following type system for Gtk. It will be
> used at runtime to construct argument lists for signal handlers and
> for setting object slots (with gtk_type_set_arg). It will also be
> used to statically describe most of the functions that should be
> exported to an interpreter. Basically, it should reflect the needs
> and capabilities of the typical high-level language that wants to
> interface to Gtk.
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
didn't like Gtk's own dynamic type code system, but I understand its
elegance.) Type conversion goes on all the time, and the types are almost
always completely static. All function parameters are completely static,
except for the signalling mechanisms -- and they use marshalling functions
which convert to static types.
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
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.
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.
> The primary issue here is robustness. Ideally, it should not be
> possible to crash your program from the high-level language. The
> second issue is to allow mostly automatic stub generation for the
> interpreter glue.
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.
Kenneth Albanowski (email@example.com, CIS: 70705,126)
] [Thread Prev