[Mono-list] Extending generic methods

Robert Jordan robertj at gmx.net
Sun Sep 28 13:36:54 EDT 2008


DraconisBG wrote:
> Hello,
> 
> Sorry if I send this to the wrong list, please direct me where I should send
> it.
> 
> I got a task where I have to modify Mono/GMCS in order to make the following
> possible:
> 
> ------------------------------------------------
> public void GenericMethod<T> (...) {...}
> 
> ...
> 
> System.Type typ = <expression that evaluates to a type>;
> GenericMethod<typ> (...);

Since generic method might also contain the type argument(s)
in its signature, your modifications must be either *much* restrictive
or *extremely* complex (and rather dumb).

For example:

public T GenericMethod <T> ();
public void GenericMethod <T> (T a);


Their call sites look like:

int i = GenericMethod<int>();
GenericMethod<int>(i);

Now let's introduce variable types:

Type t = ....;
which type?? foo = GenericMethod<t>();
GenericMethod<t>(which type??);


=> mcs+runtime must be extended to support variable types:

Type t = (computed at runtime)
t foo = GenericMethod<t>();
t.SomeOtherMethod()  // this is dynamic binding!

Congrats, we've reinvented Perl ;-)

The resolution is: to support generic methods with variable
types, the runtime must be extended to support variable
types at large. This can be done only at the cost of speed (due
to dynamic binding) and loss of type safety.

This won't be mono anymore.

Let's say we want to support only a subset:

	R Method<T>(P1, ... Pn), where R and Px	are statically typed

This is just one reflection call (the same call the runtime
would have to perform if it would be extended to support this
kind of "variable type generic methods").

Now, the only missing link is a wrapper that could be easily written
using LCG (DynamicMethod) or using a runtime icall. The latter
would prevent the code from running on MS.NET, though.

Robert



More information about the Mono-list mailing list