Why Not Use CORBA For Script Language Bindings?

tjansen asks: "While looking into the GTK library, I notice that there are a large number of GTK bindings for scripting languages: Perl, Python, JavaScript, Guile...almost every language has its own GTK binding with its own syntax that all have to be maintained (and documented) separately. The same problem exists for all C or C++ based libraries, writing wrappers for scripting languages is just a lot of work. On Windows systems COM is used to make libraries and components accessible to scripting languages. Even if the COM interface does not fit very well to a particular language, for example because they don't use the language's naming convention, they give even obscure languages a great amount of libraries with almost no work other than writing ActiveScripting bindings for the language. Why maintain separate bindings when the community could use something like CORBA for the same thing? I think the idea is too obvious and something like this should be very useful for language interoperability in general. Is anyone working on such a project?"

"Now that the free software world more or less standardized on CORBA I wonder whether anyone already had the idea to use CORBA (or at least its object model and IDL) not only for inter-process communication, but also in-process to access libraries. The idea is simple: someone writes the IDL specification and a set of skeletons that wrap the C function calls into IDL methods. Instead of producing an executable server one would create a shared library with some special symbols/functions that describe the IDL interface(s) that it implements. The script interpreter could then load the library at runtime, discover the library's interfaces and provide them to the script. Alternatively, an IDL compiler could be written that creates stubs that access the interface."