On Jul 5, 4:10 pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Thu, 05 Jul 2007 14:57:08 -0700, <gro...@lfsh.comwrote:
[...]
public T GetValue<T(string objName) {
T results;
switch (objName) {
case "Now":
results = DateTime.Now;
break;
// other cases omitted for brevity
}
return results;
}
This would then be called with something like:
DateTime dt = GetValue<DateTime>("Now");
Unfortunately, when I try to compile this I get the error " Cannot
implicitly convert type 'System.DateTime' to 'T' " at the line
assigning DateTime.Now to results.
[...]
I see two questions:
1) Generally, how to convert from one type to another in a generic
method
2) How to extract a given property from an arbitrary type by name
Regarding #1:
There may be some funny business you can play using "typeof" and the
Convert class, but it seems to me that the basic issue here is that the
compiler needs to know what you are going to convert DateTime.Now to.
Constraining T to be a struct doesn't help that at all.
If you can constrain T to be a type that you know DateTime.Now can be
implicitly cast to (or explicitly, if you want to cast explicitly), then
do that. Otherwise, you may want to look at Convert.ChangeType()...you'll
want to constrain T to be something that implements IConvertible, and the
conversion may still fail, but it may get you what you want.
Regarding #2:
In your example, you appear to be simply retrieving the property by string
name. This is something that is supported by reflection, so if that's
really what you're trying to do, that would be a much better mechanism
that trying to coerce a generic method into doing that based on a switch
statement. The code will be shorter and much more flexible (ie you won't
have to hard-code each and every property you want to support).
Pete
Pete,
Thanks for your response. The main reason for looking at generics is
that the method will return a variety of types so type coercion isn't
quite what I was looking for. The other piece of this which I didn't
mention before because I didn't think it was important, but now see
that it is, is that this will be called through remoting. I didn't
want to force the client to change the remote interface every time a
new property was added to the server object. So my intent was to
access various properties by using a string reference but also having
it strongly typed on the client side. This way I can add new
properties on the server, but the client doesn't have to change their
interface.
Ideally the client should be able to do any of the following and they
should all work: Note that it's a mix of value and reference types.
string stringValue = remoteObject.GetValue<string>("Value1");
int intValue = remoteObject.GetValue<int>("Value2");
DateTime dtValue = remoteObject.GetValue<DateTime>("Value3");
DataSet set = remoteObject.GetValue<DataSet>("Value4");
I thought about reflection in the implementation as that does avoid a
switch statement on the server side, and I may still go that route,
but I still have the problem of how to give the client a strongly
typed object rather than returning the object type that they'll then
have to convert. That just seems messy to me.
Thanks,
-GM