Re: [gtk-list] Re: Gtk and the scripting languages of the world

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.kjahds.com> writes:
> 
> I don't believe there is any single mechanism you can reliably use to
> describe an interface in a way that is transportable to all languages
> without abominations in one (like lvalue arguments being used in Perl) or
> the other (returning a list of values in C).

Yes, agreed.  But my second concern is making the interface robust.
That requires some help from Gtk (by adhering to Owen's rules, for
example).

I'll first concentrate on the robustness issue.  That will hopefully
make the interface more regular as a side-effect and that should allow
easier automated generation of stubs for a larger part of Gtk.

> > This isn't really isn't completely true - it's an enum value of state
> > GtkStateType. While its true that C is sloppy in enforcing these
> > things, this information is available to use while generating language
> > bindings.
> 
> The real trick is enforcing it in other languages. I've found Java to be
> the best for this, (but only) because it has static typing and importation
> of nested packages. The result makes it dead simple to implement
> enumerations that are type-safe at compile time and run-time. (Though
> allowing arbitrary values and bit-flags is a tad harder.)
> 
> I've yet to see any interface description mechanism that deals usefully
> with enumerations. The C technique is, of course, a cop-out. 

I think ADA got this right (I only know it from VHDL, but it should be
the same in both languages).  In ADA, functions can be overloaded
based on their return type.  This is extended to enumeration literals
by treating them as functions without arguments that return the
enumeration type (for the purposes of overload resolution).  That is,
you can reuse an identifier for several enumerations and the compiler
determines the correct type.  Further, the type of array indices can
be any `discrete' type (not just integers) and enumerations are of
course discrete types.

> [...]
> My viewpoint is that some mechanism for describing the types can
> easily be added transparently to the current code. Most of it is just
> documentation or comment headers, with perhaps comments in the actual
> prototypes to make automatic processing possible. The only important code
> change I can see is getting GTK_ARG_* o describe enums and pointers fully.

Yes.  Exactly.