IMO, Javascript is a weak/dynamic typing language and that's one of its attracting points as a script language. Casting is natural in C# but strange in Javascript.
We agree 100%. However, ClearScript's job is to bridge JavaScript with a system that relies on strong typing for basic things like method binding. With .NET's heavy use of classes, overloading, generics, and extensions, you really couldn't get very far without strong type information. That's why ClearScript usually avoids conversion and gives script code direct access to .NET objects and types.
Having said that, some conversion is necessary. It would be a huge pain, for example, if ClearScript didn't convert things like strings and integers into their script form. That's a no-brainer because strings and integers can be converted back and forth without data loss. What to do with enums, however, was less obvious. Enums exist for convenience and code readability, but their status as true .NET types involves them in overload resolution, among other things. That makes the one-way enum-to-integer conversion a serious problem. We were on the fence about enums but decided not to expose them as integers mostly for that reason.
I cannot call a CLR function with single precesion float parameters, because Javascript numbers are double.
Right you are, and thanks for finding yet another bug! It is currently not possible for script code to invoke a .NET method with a
float parameter in ClearScript. We'll fix that ASAP. Note that the only safe implicit double-to-float conversion is one that is reversible without precision loss, so in most cases you'll have to use an explicit conversion such as Convert.ToSingle() to invoke such a method. Currently doing so doesn't help, and that's what we need to fix.
My debugger shows the object type is System.Windows.Forms.Keys rather than HostObject, while print(Keys.Space) in script gives HostObject rather than "Space". So two differences from what you explained: 1) Enum values are not wrapped in HostObject in all scenarios;
The
HostObject wrapper is a native V8/JavaScript object that is not visible on the .NET side. These wrappers are required by V8's embedding model and reside in V8's internal heap. When script code passes any .NET object to a .NET method, the wrapper is stripped away; the method wouldn't work otherwise. There might be some confusion because ClearScript has an unrelated internal .NET class called HostObject.
2) Enum member's toString() does not give the enum member name but just [object HostObject].
That's correct. ClearScript does not intercept
toString(), so you're seeing its default JavaScript behavior as applied to the HostObject wraper. If you want the enum member name, use the similarly named .NET method ToString().
I'm a bit frustrated for now. I don't know if these issues are related to my usage style. I'm calling Application.Run() for message loop in script, and scripts are called back though events for UI interaction. This is normal in C# but maybe not so well for script. I know some script engines have issues in such re-entrance usage scenario.
We haven't used ClearScript with Windows Forms, but we're always looking to improve ClearScript, so we'd love to know the specifics of any problems you encounter in that environment. In any case, we'd love for you to keep using ClearScript; you have a knack for finding bugs! :)