Dynamic language bindings
by havoc
Andrew
Cowie blogs about dynamically building Java-GNOME by messing with
bytecode. These bytecode-munging libraries are
fascinating in a “wow, that’s pretty cool” way.
(valgrind does the same thing, but with machine code instead of
bytecode – valgrind is also fun to play with.)
When I looked at some of these
libs, I thought ASM
looked good – small, fast, and easy to use. It has a feature where
you can write your Java class, then convert it to an ASM code
generator, then modify that generator. (Or write your “before” and
“after” Java class, convert both to ASM, and compare.)
I’m not sure there’s a lot java-gnome could do with bytecode that it
couldn’t do with full GLib introspection and proxies,
though.
btw, someone please hack on full
introspection
for GLib… that would nicely shrink a lot of language and IPC bindings.
My wishlist for GLib introspection is that a single, simple, smart
command generate the typelib, the glib-mkenums stuff, and the
glib-genmarshal stuff. glib-mkenums and glib-genmarshal require you to
write all kinds of gunge in your Makefile that would be more nicely
done in a real programming language instead of inline shell
cut-and-pasted into every Makefile. And I wouldn’t look forward to
adding a third block of Makefile gunge to get the typelib. How about
just generating a public/installed header file, a private header file,
and a .c file from a single smart command and single input file – that
would be sweet.
(This post was originally found at http://log.ometer.com/2006-10.html#20)