Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I see the signature is:
public virtual void SetValue(object obj, object value, object[] index)
Wouldn’t this method cause the parameters to be boxed and unboxed?
Why wasn’t this method designed to be generic? Then it could even be inferred by the compiler with no boxing/unboxing penalty at runtime.
This is partly due to the fact that PropertyInfo.SetValue predates generics – reflection has been part of .NET since the beginning.
However, using generics would be difficult in this specific case, in any manner. There is no way for the compiler to infer this information, as you suggested, since the property info is gleaned at run time, not compile time. That is the purpose behind Reflection.
Instead of trying to work this into a generic method (which would probably have to lead to a non-generic implementation, in any case, due to the runtime behavior), the CLR team made sure that all objects, including value types, work as a System.Object. Yes, this causes boxing, but with reflection’s overhead, the small extra overhead of boxing a value type is not really worrisome.