Re: [gtk-list] Re: A description format for Gtk features

[Marius Vollmer <mvo zagadka ping de>]

I think I have to reply something to this post, but I haven't really
anything significant to say about ILU, I'm afraid.

I should probably investigate ILU more seriously, but I won't due to
laziness.  I first want to bring my Guile bindings into a usable form
and then worry about how to improve them.  That probably means double
work...

Owen Taylor <owt1@cornell.edu> writes:
> 
> The thing is, ILU is meant to work with languages with languages like
> C++ and Java, where dynamic typing would be a monstrosity.

Yes, but I'm still of the opinion that dynamic type checking is a
closer approximation to reality than static type checking.

> Yes. However, GTK's type system is conceptually static. (Which is good,
> since otherwise doing language bindings would be a nightmare.) And
> it seems that language bindings often need extra effort now to
> translate from GTK's dynamic representation of its type system to the
> language's static view. What you seem to be doing is adding this extra
> step for things like enums as well.

No, I hope not.  I think I have improved the dynamic type system of
Gtk by making it a more detailed model of what is really going on.
That includes adding information that an int is really an enumeration
and which one.  But the representation of an enumeration is still a
simple int.  You can (almost) ignore all extra information that is
available.

The use of the static parts of the Gtk API hasn't changed at all, I
think.

> And I do think we should try to make it possible for languages to
> provide a type-safe interface to the signal mechanism.

Yes.  I'm conviced, but I don't think that I will do anything about it
until someone has a concrete use for it.