- "Shaneeb Kamran" wrote:
> On Tue, Apr 6, 2010 at 9:24 PM, Johannes Schmid < j...@jsschmid.de >
> wrote:
>
>
> Hi!
>
>
>
> > I am not entirely sure but my guess is adding support for another
> > language would require modifications to all the applications
> > individually that want its support to be included. As far as I have
> > read (I apologize if I am wrong) GObject-introspection just makes
> > language bindings pretty straightforward but to be able to use a
> > language for scripting requires more than bindings; there are other
> > issues involved for example, mechanism for invoking the script,
> > passing objects, data conversion from the scripting language to the
> > language of the application (usually C\C++), etc.
>
> That's not true. By adding gobject-introspection you get
> language-bindings for at least JavaScript and Vala out of the box and
> python is planned. There is nothing else to do as the bindings are
> constructed a runtime (vala: compile-time) from the introspection
> files.
>
>
>
> Are the "bindings" the only thing required to properly interface two
> languages together? What about data-type mapping, data marshalling,
> memory management issues, etc? Since we have introspection now, all
> our problems are solved? Correct me if I am wrong but libraries such
> as GJS are meant to handle precisely these issues.
>
>
> But that still is not the main concern of the project; these issues
> are supposed to be handled by specific language plugins (GJS would be
> treated as a language plugin). Moreover as you say, JavaScript support
> is out (GJS) and python support will be complete soon as well
> (PyGObject?). Great, any application can now link to these two
> libraries and use two languages. What if someone writes support for a
> third language, say ruby. Your application will need to be modified to
> use that library and add another dependency. Now libraries to add two
> more languages' support, say Java and .NET, are created. So your
> application will need to add yet more (bloat) code, add another two
> dependencies raising the total number of dependencies to four. Now Lua
> supports comes in...
>
>
> The cycle continues.
>
> I perhaps failed to clearly highlight the main goal of the project:
> enable an application to add scripting support, without regard to any
> particular language, i.e. cross-language. Specific languages plugins
> will then be loaded at runtime (read: no static dependency) which will
> handle all the issues mentioned above plus generate "bindings" via
> GObject-introspection as well.
>
>
> The project is very much inspired by the Kross scripting framework
> which is available to KDE developers (
> http://www.techbase.kde.org/Kross )
So what GObject Introspection gets you is the ability for bindings that
understand GObject Introspection to instantly load those modules and use them
in the language's interpreter. It doesn't instantly allow any app to load a
plugin written in any language. For instance gnome-shell uses the gjs
interpreter and exports functions and objects through GNOME Introspection. You
can't write a python plugin unless the shell decides to embed a python
interpreter. Marshalling data isn't an issue here unless you wanted to somehow
allow different language modules to talk to each other.
Basically what you would be doing is writing a meta interpreter which would
provide a framework for developers to add plugin support without worrying about
which interpreter they would be using. I see a couple of downfalls to this
approach - specifically security, performance and issues with some languages
not being supported on one or another system. I'm also not convinced, without
a common runtime like .net and given that the client side of the web has
survived pretty well without the need of multiple languages, it is something we
wish to encourage. That being said, the proposal itself has some merit as a
project.
--
John (J5) Palmieri
Software Engineer
Red Hat, Inc.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
