By duplication of code, I mean Spidermonkey implementing its own data structures, data manipulation functions, unicode handling etc when Glib already provides such facilities. This might not be a problem on the server or desktop, but on memory constrained embedded devices (where Gnome is really starting to gain some momentum), this is an issue.

If one is to use an existing Javascript engine, perhaps JavaScriptCore would be a better choice seeing as WebKit seems to be winning the embedded browser wars, otherwise systems are going to end up with all of GLib’s facilities, some duplicated by SpiderMonkey and some duplicated WebKit simultaneously. That is a really messy overall solution. Of course, bringing in a 3rd javascript engine and running that alongside webkit is not ideal either, but unless someone comes up with a grade A 100% Gtk+ and Glib-based web browser (which lets face it, isn’t likely to happen anytime soon), there is not much choice about that.

I don’t yet have a convincing argument for implementing yet another Javascript engine, as I said in my original post, I’m just considering things at the moment. Such a task is hardly trivial, so there are lots of reasons not to do it. I feel uneasy about using SpiderMonkey and JavaScriptCore because they’ve both been hacked around and are pretty messy inside (e.g. one minute the engine is designed to be standalone, the next minute is integrated into a browser, then it is hacked out again). My comment about a Glib-based Javascript engine being easier for Gnome developers to maintain meant that the code would be more in fitting with the GTK+ way of doing things from the inside out. Of course, another project is going to involve more work than using what is already available. There are pros and cons either way.

Matt.

Eh, i’m not sure what you mean, but a (re-)implementation of javascript just to use glib is both duplication of code (you’ll be running two js implementations if you also run firefox) and harder to maintain (spidermonkey is already maintained, the new implementation is not).

Not to mention that we wont’ get any of the advantages of all the important performance work done on the mainline js engines.

This is an area I’ve been thinking about quite a lot recently and I’ve been considering development of an all-GLib implementation of ECMA-262. A GLib implementation would avoid duplication of code and hopefully be easier for Gnome developers to maintain. Perhaps a collaboration is in order? What do you think?

Matt.

There is no code atm to import a full namespace, so the functions of a namespace are not visible. However, the actual call is very similar to the one for method calls (they are both just c functions really).

Some work is happening on getting this running atm. More info later.

i added a factory function to create some gtk objects with GScript.
Just a prove-idea thing. as shown in the screenshot.

http://rainwoodman.dreamhosters.com/wp/2008/09/a-little-progress-on-gscript/

also, the js engine has a standard name ‘libjs’ (at least on fedora, try search js-devel package), in configure.ac a PKG_CHECK libjs is sufficient.

you have my full support on this. Zoo of languages is very uneasy environment to live in. And JS must-know today, because of web. Also it is impossable to incorporate useful scripts done by users(can’t imagine firefox exentions written in 15+ scripting langs) if there are no standard lang.

>vaScript prototype-based model is a bit weird,

if i’m not mistaken, next version of standard has separate classes and objects, not prototype based…

sorry for bad english

BTW: in the svn rev 4, js-gtk doesn’t work as expected because you’ve prefixed the signals with “on_”.

To each his own. Some people like .net, some not. I have no interest in arguing about that.

Anyway, i don’t think the exact language picked is really that important for the users. One can write good or bad programs in all languages, and arguing that you must use a specific language to make the user happy is just lame.