We are using the Rhino &#106avascript engine to extend functionality in our platform. We restrict access to specific classes through the scripts and I'm going back and forth with the design of the public interface that script authors will use for access to some of our core objects. For example, we want to provide our implementation of a vector interface to script authors. I have a VectorFactory that authors can use to create them, but there are some fundamental questions of how to implement it. Do I provide a Singleton where they have to call VectorFactory.getInstance() to access it, or do I just provide static calls in VectorFactory? The only benefit I can see of using a singleton is that it allows us to publish an interface that the factory implements. If, for some reason, someone wanted to write their own implementation of the factory, they could now do so. Does this even matter in the case of a factory? For any returned objects, I would certainly expect them to implement a public interface. In addition, I believe that I want to wrap all of our core objects so that they aren't actually ever visible to the end user. Thus, we have two interfaces, a public scripting interface, and an internal interface that is called from the script interface. I'm unsure of whether or not this is the best tactic however. Does anyone have information on best practices in script interface design (books, blogs, articles, anything...)? Many thanks.

Don't be too general. No one in their right mind would try and recreate the vector class if they are using your platform.

I don't have any specific examples of what you should be doing with your interface as they are always a sum of their requirements. Look at all the things you want to do with it, look at the things you might want to do with it, look at what you don't want users doing with it. Write these all down then work through your options. A path should show itself.

How much of the platform do you want to expose?

Also remember that there are two types of classes, data structure classes such as vector, matrix, particle and your program classes. You only need to protect the program classes.

[Edited by - Umbrae on March 21, 2008 4:34:22 PM]

Thanks for the feedback.

I've thought about just exposing our data structure classes directly, which is fine for vector, matrix, etc. as you mentioned. I wouldn't want to go as far as returning our entities or entity components though, which are sort of a mix between data and program. Those will need to be wrapped.

One other thought though is if you're returning your internal interfaces, they can't really change too frequently. If they do then those changes are reflected back to the script author. Wrapping our internal vectors allows us to provide a more stable interface to the script authors in this respect. If we need to change the script interface, it's a lot easier to mark something as deprecated this way. This is also important because our platform emphasizes sharing of assets between users so changes to the script interface don't only affect the author, but affect all consumers of the author's script as well.

As far as how much of the platform we want to expose, currently it's mainly just raw data. We don't expect people to be writing custom entity components for example (although in the future, I would hope someone was this ambitious).

An additional interface needs to be maintained, and can lag behind the core. As long as you are okay with that then I think what you are doing is fine. Just remember you can open it up later so only the essentials are needed at this stage.