Implement an existing scripting language for a dynamic OO program

Question

I am working on a program, which handles a lot of objects and data. As I would be able to inject manipulations by having some kind of 'API' to my application. As the application itself does the management of the objects and such, I wonder how this can be implemented. For example, the Unity3D and Panda3D engines allow a variety of languages, such as ECMA or Python for scripting. I am not looking for a 'gaming' scripting language to put in, but pointers on how to support various scripting languages.

For the sake of argument, let's say my program has objects that are of the class Cube. A cube has class methods such as rotate, move, transform and properties like color, center, size. Now, I would like to give my user the possibility to use for example JavaScript to manipulate the object. My 'core' program however is written in Ruby.

1. Would I have to write an entire package that will evaluate the user code and its syntax (as implement an own version of JavaScript) from scratch? Or are there existing packages, skeletons, frameworks, gems, etc.?
2. How would I implement security to give the scripting language only to the classes that are allowed to be manipulated (for example, an attribute that marks the class as 'manipulable').

I have always wondered how Enterprise applications did this trick (and Game engines too...), so thank you for the help and feedback.

Answer 1

If your core program is written in Ruby, I don't see why you would want your scripts to be written in anything but Ruby—except maybe for sandboxing (see below).

Would I have to write an entire package that will evaluate the user code and its syntax (as implement an own version of JavaScript) from scratch?

No. There are many packages you can incorporate into your program. If your program were written in C, or even if it provided a C interface, your decision would be easy: the programming language Lua is designed to be embedded into C programs with very little effort. I have done it at least a couple of dozen times.

How would I implement security to give the scripting language only to the classes that are allowed to be manipulated (for example, an attribute that marks the class as 'manipulable')?

You do this by setting up the collection of names that is visible to scripts—as a programming-language guy, I would say you control the environment (a technical term for talking about access to names). In the case of Lua, for example, you would hand each user's script an environment that allows the user to name exactly the functionality you want the user to have, and no more. If the script can't name it, it can't be used. This job is generally called sandboxing. (As in, "put the user in a sandbox and don't let them out.") Sandboxing via control of the namespace is usual in other languages besides Lua.

I have always wondered how Enterprise applications did this trick (and Game engines too...)

I don't know how to summarize this trick briefly enough for an SO answer. But the general idea is:

• The scripting language has a bytecode interpreter

• There is a carefully designed protocol for calling between scripts and C

For a deeper view, read Roberto's book Programming in Lua; an earlier edition is free online.

Answer 2

I'm not sure I completely follow your requirements, but would something like a RESTful approach work for you? REST is usually thought of in client/server terms, but I think some of the ideas might be applicable here, too.

The basic concept might be that you expose representations of the objects (probably in JSON or XML) via your API. Clients would fetch these representations, make whatever changes they wanted, and then submit the modified versions back to your program. Your program would validate the changes and (assuming they were legal) apply them.

This seems like it would allow you to be quite agnostic about what sort of scripting languages were used, should be flexible and easy to understand for users, and gives you a clear place to implement your security policies.

Incidentally, while I have no idea if this is how scriptable game engines work, I have seen some Enterprise systems that exposed APIs similar to this (though usually as a web service rather than accepting user-written scripts).