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

[Kenneth Albanowski <kjahds kjahds com>]

On 25 Aug 1997, Marius Vollmer wrote:

> > 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.
> 
> Could you elaborate on these technical issues?  Right now, I only see
> problems with the performance, because my Scheme glue has to search
> the list of enumeration literals for every call.

My Perl code does exactly the same thing. However, it's difficult to add
new types, as C code is doing the type checking and could, in theory, be
optimized to use a decent hash to speed the proccess.

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. 

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

> Yes, agreed.  Maybe the generation of (simple) stubs for new widgets
> can be automated enough that it is feasible to do it during the normal
> configuration/make of the new widget.

Yes, that would be my hope. Actually, a large chunk of the Perl code (that
isn't involved in adapting how functions return values) is essentially a
mechanical translation of various types.

> I hope that in the end my proposal turns into a precise description of
> most of the types that appear in the Gtk API.  With them, you could
> document the calling conventions of Gtk in a highly stylized manner.
> That is both easier for the documentation author and for the user to
> comprehend.

Yes, that's exactly the sort of thing we need.

> In fact, now that I've written the paragraph above, I see the things I
> try to achieve with my posts here not so much as to change Gtk to my
> own liking, but rather to document enough of Gtk in such a highly
> stylized manner.  It should be so stylized that even a program can
> understand it.

Bingo.

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

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