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

[Owen Taylor <owt1 cornell edu>]

Maurizio Vitale <Maurizio.Vitale@esat.kuleuven.ac.be> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
>
> IDL: can generate stubs in different language (one implementation, ILU
> from xerox PARC does C, C++, Java, Common Lisp with a somewhat less
> supported/debugged Guile stubber).
> IDL compilers are freely available, don't have to design/document your
> own and you get a big chunk of CORBA interoperatibility for free.

I've done a bit of research recently on this issue, and I thought I'd
report my results.

My basic conclusion is that IDL isn't suitable for describing the
existing practice in GTK (I'm mostly talking about ILU's subset
of IDL, but the conclusions here are, I think, the same for full
IDL, and for ILU's ISL.) Some of the relevant points.

 - IDL doesn't support flag types. (OK, you can define constants
   and do bit operations on them, like in C, but this is by definition
   not typesafe, and highly unnatural in most languages)

 - GTK's callbacks can't be represented very well. (Not suprisingly -
   they are fundementally not type safe)

 - (minor) All functions in IDL are member functions.

However, before throwing out the concept of IDL, let me toss out
another possibility. Most of the issues above are issues that would
be encountered in interfacing to any object-oriented language. So it
would be possible to define a high-level interface to GTK in IDL, bind
GTK to that, and then make all other languages talk with the high
level inteface. (Presumably using ILU)

  Python \
	  \
  Guile	------ ILU ---  Gtk
	  /
  Perl   /

Advantages:

 - There would be only one interface to maintain for any language
   supported by ILU.

 - An ILU interface will probably have to be written eventually for
   GNOME.

 - You could effortlessly have several languages running in one
   process (and different processes!) using the same widgets.

Disadvantages:

 - People would have to have ILU installed.

 - There would be some double-thunking overhead

 - The interface might not be perfectly natural for every language.

Flag types would presumably be represented in such an interface by a
sequence (i.e., array/list) of enumeration elements. This is good
for most  languages except ones which are fundementally C-like
(C++/objective C).

There would have to be a separate object type for each species of
callback. The default interface might not be to smooth for all
languages, for instance, in Perl you would have (approximately):

  $button->signal_connect_clicked ( new Gtk::Button::Clicked (
		                    \&callback, $arg1, $arg2 ));

Though syntatic sugar could be provided.

Such an approach to language interfacing would definitely have its
advantages, and we may end up there eventually in any case. But it may
be over-ambitious in the short term, especially since there good
interfaces already exist for most important languages.

Regards,
                                        Owen Taylor