On 10 February 2010 09:29, jideel <[email protected]> wrote: > Thanks for your response. > You're probably right, perhaps it's not the right tool.
Sounds to me like you might be able to get away with just a few key functions in a scripting language, and keep the rest static. A vala object that wraps a TCL interpreter for example, should be pretty simple. Then leave all the heavy lifting to Vala, a database or two, etc. Python I think will let you save the bytecompiled code, not sure about Perl or Ruby or what-not. But they can also get a little hairy around the embedding API, Python especially if I recall correctly... But something simple like TCL, used to implement just a few specific method of an otherwise generic object, might be all you need. Cache the objects after they've been used, to try and re-use the byte compiled function definitions, and should be pretty sweet. If you DO want to go compiled code for speed, you could try sticking to straight C. That compiles pretty darned fast, especially when it's not needing to pull in loads of libraries and what-not, and again, wrap it in a generic Vala object that provides the main functionality. The web interface can give the impression of object orientated programming by providing a template into which you plug your function definitions. Doesn't mean they have to actually end up as compiled objects. I used to play a text-based MUD back in the old days, where every room, item, monster, etc., were all small C programs using a core library. The owner of an object could submit updated code, which was put through an automated sanitiser, and if it passed, compiled and stored in an object storage directory. Next time anything requested that object the system would execute it, with the core library acting as a remote procedure call mechanism over the standard IO. When the last active instance of the object vanished (no one in any room it's in, or not being carried by anyone presently active in the game), the executable was told to exit, and all that was left was the binary file in the object store. (The source code was kept in a separate public library...) >From what I remember of GModule, there's two main problems. 1) the GType system doesn't like unloading stuff; once a type is defined, it tends to stay defined. Various strings and things get added to a static storage space and can't be free'd, and stuff like that. So unloadable modules need to be wrapped, taking care that none of the unloadable parts will ever find their way into persistant corners of the object system. 2) I'm not entirely sure that module unloading is even entirely portable to begin with, in which case they've provided the mechanism to support it, but no implementation since there isn't a generally reliable one available. But again, all that becomes mute when you're only defining a few methods and wrapping them in a generic object. Only the generic parts will find their way into persistant storage spaces, and and once the instance of the object is free'd, the library implementing its specialised methods can be unloaded fairly easily. Fredderic _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
