1
Vote

It should be possible to create a ScriptRuntime without specifying any languages

description

In the default configuration, ScriptRuntime.CreateFromConfiguration() throws an exception tht no engines have been configured. This is a counter-intuitive place for the error, many simple hosting applicatoins will want to simply declare a default ScriptRuntime as a initialized (possibly static) memeber, and this is hampered by having to wrap it in error handling.
 
If and when the application attempts to create a ScriptEngine is the time to raise any errors about availablility of a specific engine. Even if there are no engines, other features on the ScriptRuntime might be useful.

The built-in "invariant" language, which is always available to a ScriptRuntime through the Operations property, should count as a language when creating a ScriptRuntime.
 
The TestDefaultRuntime() function in the attached unit test module demonstrates the problem.

file attachments

comments

billchi wrote Dec 10, 2009 at 4:49 PM

The ScriptRuntime is designed to be immutable after creation.



** Closed by billchi 12/9/2009 1:53 PM

BurtHarris wrote Dec 10, 2009 at 4:49 PM

What's immutability got to do with it?

I'm just saying throwing an exception from the ScriptRuntime constructor about no languages is misplaced. It would make more sense to wait until a call that attempts to create a ScriptEngine to complain it can't be done.

P.S. Methods like LoadAssembly() on ScriptRuntime seem to violate the concept of immutability.

BurtHarris wrote Dec 10, 2009 at 4:57 PM

Also, the ScriptRuntime.Globals property is settable, how can that make a ScriptRuntime immutable?

billchi wrote Dec 15, 2009 at 11:33 PM

In discussion with Dino and Tomas, while the ScriptRuntime would not be useful, there's not reason not to be more in the dynamic language spirit to let you go as far as you can before getting an error. A real scenario here may be that an app had no config but consed an SR, and it should run fine until some user gesture to actually run script code caused the SR to fetch an engine ... then it could signal an error.