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 _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list