Is there a good way to extend collection type conversion logic?

[handerss-spotfire]

As far as I understand, JavaScript arrays extend IList, and IList which means they can only be used when calling methods whose argument are such collections. However, usually in C# we define APIs which take collections with stricter types, e.g. IEnumerable. Calling these functions requires interacting with the ClearScript runtime to obtain an appropriately typed collection. Is there a way to inject this logic without leaking ClearScript into the script, and without having to add IEnumerable overloads and similar to each API where this occurs.

It would be nice if we could define type mapping logic on the C# side. So if ClearScript cannot resolve a method with the appropriate parameter types then it tries to lookup a conversion function which makes the types match. That way a script author can write SomeMethod([1, 2, 3]) using method with signature SomeMethod(IEnumerable<int>) without having to know anything about ClearScript.

In this case we would define a mapping from IList<object> to IEnumerable<int> (or some other type which implements that interface), and register it with the engine.

[ClearScriptLib]

Hi @handerss-tibco,

However, usually in C# we define APIs which take collections with stricter types, e.g. IEnumerable.

IList inherits from IEnumerable, and IList<object> from IEnumerable<object>, so JavaScript arrays should serve as valid arguments for those parameter types. On the other hand, you're probably asking about strongly typed collections.

Is there a way to inject this logic without leaking ClearScript into the script, and without having to add IEnumerable overloads and similar to each API where this occurs.

There's almost certainly a way to set up a JavaScript API so that scripts needn't directly invoke ClearScript services. However, since ClearScript provides no simple hook for argument conversion, there's probably no avoiding per-method setup of some sort. Overloads are one possibility, as are extension methods, the facade pattern, etc.

If you can say more about your scenario, we'll be happy to provide more specific recommendations.

Thanks!

[handerss-spotfire]

IEnumerable was supposed to be IEnumerable<int> but Github markdown ate my arrow brackets because I forgot backticks. You are right, I am asking about strongly typed collections.

My scenario is that I have many methods which take strongly typed collections of different kinds. I want script authors to be able to use these methods without having to expose them to ClearScript-isms and without creating overloads in each such instance.

For pretty much all such cases I simply want a conversion method which runs through the IList<object> and tries to cast each object to T and then returns the desired collection type. E.g. I want to register List<T> ConvertToList<T>(IList<object> objs) => objs.Select(o => (T)o).ToList();. Such that script authors can just call my List<int> methods with regular JS arrays.

[ClearScriptLib]

E.g. I want to register List<T> ConvertToList<T>(IList<object> objs) => objs.Select(o => (T)o).ToList();.

How would ClearScript determine what to pass for T?

[handerss-spotfire]

ClearScript already throws a helpful error message for this scenario at the moment (calling void DoSomethingWithIntList(List<int> aType)):

'Error: The best overloaded method match for 
'DoSomethingWithIntList(System.Collections.Generic.List<int>)' has some invalid arguments

So my assumption is that ClearScript knows what T is (or should be) at this point.

[ClearScriptLib]

So my assumption is that ClearScript knows what T is (or should be) at this point.

Unfortunately, no.

Method binding in .NET is a rather complicated affair – so much so that ClearScript makes no attempt to duplicate the algorithm. Instead, it delegates the task to portions of the C# compiler that are accessible at runtime. It's the compiler that throws that exception.

To put it another way, ClearScript provides a call signature that the C# compiler binds to a method – one that it may have selected from a list of overloads according to a complex ruleset, constructed from a generic method definition, etc.

Because we don't have the method when we're building the call signature, we have no way of knowing what specific argument conversions might be applicable.

Sorry!

[handerss-spotfire]

Alright, thanks for the great reply!