Issue with availability of inherited methods

[ChrisHuebsch-FLIG]

Hi,

I have a "super host" application mainly written in C++ (third party code).
This application has an extension API which allows to run custom CLR-Code (C#, VB.NET, ...) with the help of a .NET-VM within that application.

So I use that API to write a custom "plugin". That custom plugin uses ClearScript to implement some qickly changing components in JavaScript. (I use the V8 engine.)

Now I have a situation where the control flow jumps quite complex back and forth from .NET code to native code to JS code.

After some time, I reach a point, where the native (C++) code calls a function in .NET.
I take this call and route it to my JavaScript engine. (like so: engine.Script.myFunction())

The JS engine then calls a method on a host object (object1), which returns by signature an instance of an abstract class (let's name it SuperClass). (lieke so: object2= object1.methodX(), which has return type SuperClass)

The returned object (object2) is an instance of a subclass ("SubClass") of the SuperClass.

I can use all members of the SuperClass with object2, but no member of the SubClass is available.

I enabled reflection for the engine, and used "obejct2.GetType()" in the debugger. The correct "SubClass" is listed as type name.
GetMethods and GetProperties also list all methods and properties of the SubClass.

But using those, fails with "The object has no suitable property or field name".

Is there any option to enable to make that work?
I already tried UseReflectionBindFallback=true, but without any luck.

And, if there is not such a "magic setting", can someone give me a hint if I can attach a debugger to ClearScript and find out at which point the members are resolved? Perhaps I can contribute with some information?

[ClearScriptLib]

Hello @ChrisHuebsch-FLIG,

By default, ClearScript restricts field, property and method return values to their declared types – SuperClass in this case. That's critically important for type correctness.

Suppose that, in addition to methodX, there were also two overloads of methodY as follows:

public void methodY(SuperClass arg) { ... }
public void methodY(SubClass arg) { ... }

Now suppose that your script code did this:

object2 = object1.methodX();
object1.methodY(object2);

Which overload should be invoked on the second line? With type restriction, overload selection correctly mimics C#. Note that, in C#, SubClass methods would also not be available without an explicit downcast.

There are several ways to work around this.

First, you could perform a downcast in script code using cast, but that's probably not what you want, since it's a bit unnatural for script code to perform casts.

Second, you could decorate methodX to expose its return value's runtime type. This is the most common solution:

[ScriptMember(ScriptMemberFlags.ExposeRuntimeType)]
public SuperClass methodX() { ... }

Finally, you could disable type restriction globally via DisableTypeRestriction. We don't usually recommend this, as it can break type correctness as shown above, but it can be useful if the attribute approach isn't feasible.

Good luck!

[ChrisHuebsch-FLIG]

Thank you for your quick reply. I will check wich works best.