1 Oct 2003 tjansen   » (Journeyer)

GObject for language-independent APIs
mikehearn proposed using GObject as a way to share libraries between different languages and platforms. I think there are two problems with GObjects that are much bigger than those that he mentioned:
  1. GObject does not allow to browse the methods of a class at runtime and invoke them (what Java calls introspection and MS Automation). This is needed for making scripting/dynamic languages first-class citizens, as it is not realistic to expect that wrappers for a large set of libraries and languages can be kept up to date. Any viable contender for cross-language APIs needs to offer introspection
  2. GList, gchar strings and friends are a problem, because the performance cost of converting them to the high-level platform's types are high. gchar strings would need to be UTF8-en/decoded for every call if the platform uses unicode. GLists would have to be converted into the platform's native list representation, which is a o(n) operation. The only clean solution is that every type except numbers must be represented by a GObject as well.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!