On Fri, Sep 03, 2004 at 02:00:12PM -0700, Daniel Rogers wrote: > P.S. It seems silly that one of the biggest attractions of GObject is > that you can make all kinds of fancy language bindings for it, yet there > are still only a handful and think of this: one of the goals of GObject > is to be able to write language bindings so that one does not need to > use GObject. . . Exactly. The idea is that you give the freedom to the application programmer to choose the language that they want, and let them working with the library in the language's native way of doing things. Yes, GObject is horribly lowlevel. C is horribly lowlevel. It's far far nicely to make GTK+ application in say, Python, than it is in C. But GEGL is aimed at being *infastructure*, not an application. Part of being an infastructure developer is sharing your ball with people. Sharing is hard work sometimes, but hey, it means more potential users of your library. GObject has bindings for C++, Perl, Python, Java, Ruby, C#, and a bunch of others I don't recall at the moment. So that covers pretty much all the major languages these days. One could call it a "handful", but it's a pretty big hand. And it still gives the freedom for the poor, beat up C programmer who actually *wants* to use C. C++, Java, etc. are hard to interoperate with. Not due to problems inherent in the language, but problems in the common implementations. C++ ABI isn't constant on all platforms, Java on many platforms means a huge, inefficient, and shoddily written JVM... If the big issue is the mass of boilerplate code needed to make objects, there's basic stuff like G_DEFINE_TYPE, or generic code generators like gob, or domain specific generators like GEGL's opgen... -Manish
