Re: Scaffold, plugins and language independence

["John (J5) Palmieri" <johnp martianrock com>]

On Mon, 2004-02-09 at 14:51, Bart Van Rompaey wrote:
> On Mon, 2004-02-09 at 13:13, Christian Leutloff wrote:
> > Hello,
> > 
> [cut some earlier postings]
> > 
> > Regarding the language independent execution of plug-ins it is worth to 
> > have a look of the technology used by mono/.NET. E.G. using the type 
> > system developed for .NET languages it is possible to directly call 
> > functions written in different languages. The usage of the same type 
> > primitives eleminates the need of marshalling and re-marshalling the 
> > variables.
> > 
> > Bye
> >    Christian
> 
> If you stick to the .NET platform, you can indeed "interoperate" between
> different languages (interoperate = use/inherit classes written in
> another language, in fact all languages are compiled to the same ilasm,
> so you work with only one language), given that you have a .NET compiler
> for the language (more precise: one that follows the common language
> specifications). When you look at Mono, there are only a few such
> compilers so far. 

While Mono at some point may be one of our targets right now C is the
main target.

> Now look at what Scaffold is intended for: support software development,
> mainly for Gnome and Gtk. We're talking about glib c, c++, python, java,
> c#, ... then. For most of these languages, there is no .NET compiler for
> Mono (not yet). So although .NET looks promising, it's not really
> usefull as interoperating tool/medium in Scaffold I think.

This is correct.

> I'm not sure if GModule/wrapping can provide a solution here either:
> could all those languages be wrapped? If one wants to support all of
> them, meaning development support in the form of tools (build, cvs,
> debugging, syntax highlighting, intellisense, ...), I think the easiest
> way is writing the language specific parts in their own language (by
> means of plugins). 

Syntax highlighting is already taken care of by GtkSourceView.  As for
the other stuff in some ways you are right, we would need to support the
language in order to add stuff like debugging.  However our goal is not
to wrap every single language.  A majority of us are Python enthusiasts
so that would be the first to be wrapped however the main goal is not to
support python but to make it easier to write plugins.  In the future we
may feel that we want to add a python debugger or someone will come
along who really needs it so they write it.  The goal is to be a C
development environment first and add on as the need arises.

> Java and C# have both their API classes to reflect on
> the intermediate languages files (class/dll/exe), using these
> functionality is the easiest way to get the necessary information needed
> for some tools (in special: class/method browser, intellisense, ... ).

In order to do this not all interfaces need to be wrapped.  So it would
be easy to add languages without having too much overhead.  One of the
things I am looking to do is have the ability to wrap C functions and
constructs directly from a class browser with a simple "export method"
context menu.  

> So I thought communication between plugins in those different languages
> and the "core" could be done using Corba/Bonobo, since all those
> languages have libraries for this. The core can be further developed in
> glib c, and can keep using gdl, gnomebuild, ... . This way, you can
> provide the largest possible freedom to the plugin writer too.

We dropped Corba/Bonobo for the simplicity of developing with GModules. 
The old plugin system relied heavily on Corba/Bonobo which turned a lot
of plugin writers off.  Interfaces may later be wrapped in Corba/Bonobo
bindings but for now a nice C interface with Python bindings seems like
the path of least resistance.  Even the Glade-3 developers have frowned
on using Bonobo and instead wanted a modularized C API.  

> These are just my thoughts of a Gnome IDE, don't know if you agree. Any
> comments on this?

Keep commenting.

> Bart.

--
J5