Open GoogleCodeExporter opened 8 years ago
Issue 6 and 7 are related. This is because ProcessAttributes is called in the
constructor of MethodGen. At that time, due the the new way of specifying the
parameter, no parameter exists yet.
In the ProcessAttributes, it try to match the current method with interface, it
won't
match for any method actually takes parameter(s).
I can see two solutions to this:
1. The Method() call should return an intermediate type instead of MethodGen, say
MethodDef, MethodDef parameter definitions, not MethodGen. And MethodDef should
have
implicit conversion to MethodGen and CodeGen. That way, when the MethodGen
constructor is invoked, method signature is final.
2. Drop off the new parameter syntax. Introduce something like below example, I
actually like this approach better and I'll explain why.
g.Public.Method<ReturnType>("MethodName", Parameter.In<int>("p1"),
Parameter.Out<string>("p2"));
The overloads are:
MethodGen Method(Type returnType, string methodName, params Parameter[]
parameters);
MethodGen Method<T>(string methodName, params Parameter[] parameters);
And in Parameter
public class Parameter {
public Parameter(Type type, string name) : Parameter(type, name, Direction.In) {}
public Parameter(Type type, string name, Direction d) { ... }
// ParameterInfo has type name and direction.
// This is very useful when you are implementing an interface by reflecting it.
public Parameter(ParameterInfo pi) { ... }
public static In(Type type, string name) { ... }
public static In<T>(string name) { ... }
public static Out(Type type, string name) { ... }
public static Out<T>(string name) { ... }
public static Ref(Type type, string name) { ... }
public static Ref<T>(string name) { ... }
public static From(ParameterInfo pi) { ... }
}
Original comment by kenne...@gmail.com
on 29 Oct 2009 at 4:55
OK, so let me explain why I prefer 2nd option. I'm writing code to dynamically
create
a decorator based on any interface. I use reflection to get all the members of
an
interface and implements each member by delegating the call down to the target
instance. And sure I do something more before and/or after the call. With the
new
.Parameter() approach, it is very cumbersome to do this.
The new proposed approach works for both manually specified parameters or
programmatically generated ones.
Original comment by kenne...@gmail.com
on 29 Oct 2009 at 5:27
Hi,
can you please provide an example on how cumbersome it can get with the new
syntax? I may have
missed something, but I don't see that much difference between the two, other
than that with
the 'provide all parameters at once' approach you have to create some
intermediate array of
parameters.
The bug itself can be fixed rather easily by simply moving the
PreprocessAttributes call to
CreateMember(), where it should have been from the beginning.
Thanks & Regards,
Stefan
Original comment by StefanSi...@gmail.com
on 22 Dec 2009 at 11:08
Original comment by StefanSi...@gmail.com
on 22 Dec 2009 at 11:09
Issue 7 has been merged into this issue.
Original comment by StefanSi...@gmail.com
on 22 Dec 2009 at 11:10
Original comment by StefanSi...@gmail.com
on 22 Dec 2009 at 11:34
Original issue reported on code.google.com by
kenne...@gmail.com
on 29 Oct 2009 at 3:05