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

[Marius Vollmer <mvo zagadka ping de>]

Kenneth Albanowski <kjahds@kjahds.com> writes:
> 
> However, more importantly, if a binding were written in Java, or some
> other language that can do type-safe enumerations, then adding new
> enumerations at run-time would be a very substantial problem. Java happens
> to be dynamic enough to make it possible. C++ is not. 

Ok, I'll try to emphasize static applications in the proposal.  The
primary definition of the types and the exported functions will be
found in some definition files that are distributed (and installed)
with Gtk.  Maybe these definition files are automatically generated
from the C sources, maybe part of the C sources are generated from the
definition files.  I've not made my mind up about that.

For dynamic uses of the definitions, they will be automatically
translated into C data structures that ca be queried at run-time.  But
you don't have to, if you don't want to.
 
> > Agreed.  But we should allow these new widgets to bring new types with
> > them.  One obvious new type is the widget type itself, but other could
> > be enumerations, etc.  We probably can't allow new widgets to
> > introduce new fundamental types, like GdkPoint.
> 
> Agreed. At that point, something like ILU is probably preferable, it
> anything is.

Isn't that overkill?  I don't know how complicated ILU is and how much
existing work could be reused, tho.
 
> > To be completely honest, I'm currently tempted to rewrite gtkenums.h
> > into a more Lispy syntax.  But that probably brings more trouble than
> > it's worth.
> 
> As long as it can be parsed in Perl, I won't mind. But LISP isn't fun to
> parse in perl. ;-)

Which -- of course -- isn't LISPs fault.  LISP is notorious for its
trivial syntax.  If all you have is Perl, everything looks like
/etc/passwd. ;-) [Really, no offense intended.  If we two work
together on the high-level language issue, the result must be good for
everybody...]