Re: [gtk-list] Re: auto-generating language bindings
- From: "Manuel M. T. Chakravarty" <chak is tsukuba ac jp>
- To: gtk-list redhat com, mvo zagadka ping de
- Cc: olly scatcat demon co uk
- Subject: Re: [gtk-list] Re: auto-generating language bindings
- Date: Mon, 15 Mar 1999 11:20:09 +0900
Marius Vollmer <mvo@zagadka.ping.de> wrote,
[...]
>
> It will definitely pay of to start with one of the formal descriptions
> of the Gtk+ API used by one of the language bindings and try to stay
> compatible with it. I suggest you look at the Python bindings.
>
> "Olly Stephens" <olly@scatcat.demon.co.uk> writes:
> > 2. it doesn't appear to define any of the signals
>
> All necessary information about signals can be found at run-time. If
> that is not good enough, you are very welcome to add signal
> information to the defs files. I can give you some hints how to do
> that in the `right' way.
It appears to me that the language bindings so far focus on
languages that have a rather weak *static* type system
(Guile, Perl, Python) or are relatively close to C (C++,
Objective C). I am currently developing a binding
<http://www.score.is.tsukuba.ac.jp/~chak/haskell/gtk/> for a
language, called Haskell, that has an extraordinarily
powerful and strong static type system. This gets me into
all sorts of trouble, because I have to provide a reasonably
typed view onto GTK+. This also excludes to get the signal
information at runtime and makes it difficult to use the
existing API descriptions to generate the binding code.
Modula-3 maybe somewhat in between here.
Cheers,
Manuel
DISCLAIMER: I don't like to start a discussion on the
merits of dynamic versus static typing on this
list.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]