Running with Code Like with scissors, only more dangerous


Bridging the gap between Jurassic and the DLR, Part One

Part One: ObjectInstance derives from DynamicObject

A while back I posted that I was joining the Jurassic team; Jurassic is an open-source JavaScript engine for .NET. If you’ve ever gone through the long search for a JavaScript implementation on .NET (other than JScript.NET, of course), there are a bunch of incomplete implementations, and if you’re lucky enough to find the blog about the Microsoft project of JScript running on the DLR (once called Managed JScript), you’ll find that it was an implementation that was specifically designed to give design feedback on the DLR itself, and was not planned to be carried forward into production. Personally I think that’s too bad, but I’m happy to see a couple of projects (notably, Jurassic and IronJS) that have stepped up to fill the gap.

I had considered implementing IDynamicMetaObjectProvider, but inheriting from DynamicObject seems to be a better design decision all-around. Since all of the other JavaScript objects inherit from ObjectInstance, it’s a simple matter of overriding its virtual methods instead of creating a new implementation of DynamicMetaObject for each class in the hierarchy.

I’ve created a new library project within the solution as well as a simple testing project to advise on the API as well as to step into my DynamicObject overrides. Here are some simple components:

// These are new:
using System.Dynamic;
using System.Diagnostics;

// This is updated
    public class ObjectInstance
        : DynamicObject
        , System.Runtime.Serialization.IDeserializationCallback

// The class exists as normal
        public override bool TryGetMember(GetMemberBinder binder, out object result)
            result = GetNamedPropertyValue(binder.Name, this);
            if (result != null)
                return true;

            return false;

        public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
                result = CallMemberFunction(binder.Name, args);
                return true;
                result = null;
                return false;

        public override bool TrySetMember(SetMemberBinder binder, object value)
            this.AddProperty(binder.Name, value, PropertyAttributes.FullAccess, true);
            return true;


This is the source of the test application. It’s very straightforward:

        static void Main(string[] args)
            ScriptEngine engine = new ScriptEngine();

            engine.SetGlobalFunction("write", (Action<string>) ((s) => { Console.WriteLine(s); }));
var a = {
    A: 'A',
    B: 20,
    C: function() { return 'Hello'; }
            dynamic obj = engine.Evaluate<ObjectInstance>("a");
            obj.D = "What's that?";

            Console.WriteLine("C#: " + obj.D);

write('JavaScript: ' + a.D);


We create a global function ‘write’ which writes a string to the console. Then we create a global object a with properties A, B, and C. We then use C# to retrieve the value of this object as a dynamic. This is what provides us access to the DynamicObject‘s overrides intrinsic within C#’s support of the DLR. We then access each property (which each return a dynamic) and, happily because of Jurassic’s automatic conversion of primitives to their respective .NET types, when these values are returned as dynamic, they can be automatically converted to their appropriate types for their Console.WriteLine parameter. You can see that we invoke TryGetMember on A and B, TryInvokeMember on C, and TrySetMember and then TryGetMember on D.

OK, it’s late, so I’m not going to stick this out anymore right now. I’m not even sure if the previous paragraph was particularly coherent. :-)

There’s a lot to update: it doesn’t support case-insensitive languages (like Visual Basic), it’s not particularly good at error checking, and I haven’t dealt with any other components yet. The good news is that it seems like we should be good to go for the rest of the components.

Next time, we’ll look at other classes, like ArrayInstance, FunctionInstance, and more.

Comments (0) Trackbacks (1)

Leave a comment

ERROR: si-captcha.php plugin says GD image support not detected in PHP!

Contact your web host and ask them why GD image support is not enabled for PHP.

ERROR: si-captcha.php plugin says imagepng function not detected in PHP!

Contact your web host and ask them why imagepng function is not enabled for PHP.