Michael Bayne wrote:
> > In the case of methods, there exists a DynamicOnlyMethodMethodWrapper
> > which implements ICustomInvoke, but it's private to DotNetTypeWrapper,
> > so it is currently not possible to use it from MemberWrapper.Create().
> > I can, of course, change the visibility (and I'm about to try that),
> > but that doesn't look like an old "slow" reflection implementation
> > that was later replaced.
> >
> > Am I barking up the right tree here, or should I be using some other
> > reflection implementation?
>
> OK, clearly using DynamicOnlyMethodWrapper is not the right approach,
> but I've created a new MethodWrapper that implements ICustomInvoke
> essentially thusly:
>
> object ICustomInvoke.Invoke(object obj, object[] args,
> ikvm.@... callerID)
> {
> return method.Invoke(obj, args);
> }
First of all, sorry for confusing you. The slow reflection support is only implemented for fields, not methods and I forgot that.
The above approach is possible, but I think it is better to simply modify the reflection code itself (after it checks for ICustomInvoke, you can do something like this:
mw.ResolveMethod(); // this is not necessary in your scenario, only when running in dynamic mode
MethodBase method = mw.GetMethod();
method.Invoke(obj, args);
> Should I be doing any sort of argument conversion before calling into
> CLR reflection?
Usually not, but there are some weird cases.
Unfortunately, I don't have a list of "special" things that you need to worry about. The current design leverages the fact that the normal IL emit code is used, so it will do the same thing for reflection as normal method invocation, so I don't really need to worry about any special cases at a global level.
The one thing I do remember is that you need to handle "ghost" interfaces: java.io.Serializable, java.lang.Cloneable and java.lang.CharSequence. These need to be wrapped for the arguments and unwrapped for the return value.
For more hints on special cases see FieldAccessor<T>.IsSlowPathCompatible().
Regards,
Jeroen
|