Auto-wrapping of CLR return values

Dec 30, 2009 at 12:34 AM
Edited Dec 30, 2009 at 12:34 AM

I've been having some headaches caused by the fact that Visit(MethodCall methodCall) autowraps the result of a CLR method with Global.WrapClr(), which means (if I understood it correctly, which I think I have) that even simple things like Numbers, Strings, etc. will be wrapped into a JsClr object.

The problems come from the fact that the expression typeof obj on a simple object wrapped in a JsClr object will return "clr" instead of "number", "string", etc. It almost makes it impossible to return "undefined" / null.

So I dug down a bit further, found the end of Visit(methodCall methodCall), and line #1557 that used to look like this:


Result = Global.WrapClr(result);

Now is replaced with this:


JsObject wrapped;

if(!Global.TryWrap(result, out wrapped))
    wrapped = Global.WrapClr(result);

Result = wrapped;

Global.TryWrap, is just a nicer version of Wrap that doesn't throw an exception - like Int32.Parse vs. Int32.TryParse. What it does is it first tries to convert the return value to a normal javascript object if possible like Number, String, etc. And if that fails, fallback and wrap it inside a JsClr object.

Dec 30, 2009 at 9:24 AM

We have already improved this behavior in the trunk. I think you should use this version instead of the releases, as you work with the source code.

l/p: svnuser/svnuser


Dec 31, 2009 at 7:51 PM
Edited Dec 31, 2009 at 7:52 PM

<please ignore...replied to wrong thread>

Dec 31, 2009 at 8:07 PM

I ran into a very similar issue in two other places (based off of the 0.86 codebase.)  In both cases, I inserted the following code which seemed to fix the issue (though not perhaps as encapsulated):

if (value is ValueType)
    Result = new JsValue(value, JsValueType.CLRObject);
    Result = new JsClr(value);

I ended up making this change in ExecutionVisitor.Visit(Indexer) and ClrFunction.Execute.  There are likely other places as well, but I simply haven't run into them yet.  I'm not certain this has exactly the same resultant behavior as what fholm proposed above, but I think they are both addressing the  same underlying issue.