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