« Article on Tech Head BrothersPhp for Visual Studio (Php4VS) »

8 comments

Comment from: Fabrice [Visitor] · http://weblogs.asp.net/fmarguerie
Another tip: you can use a constraint on your method to restrict the type parameter. Here, you seem to expect that T be of type Class1 or inherited, so you should write:

static T GenericMethod(T item) where T : Class1
{
}


In this case, there should be no need to cast to Class1 because item is a Class1.
06/02/08 @ 02:33
Comment from: Stephane [Visitor]
In addition, c1 = (Class1)item; will throw if item is not Class1 whereas c1 = item as Class1; will not, so you have to test for null.

Another Try c1 = (Class1)(object)item;
06/02/08 @ 09:25
Comment from: Nicolas Penin [Member] Email · http://dragon-angel.fr
You're both right. But, the only thing I wanted to introduce was tips to enable cast in Generics and to call generic methods without writing the generic type.

To answer to your remark Fabrice, you're right, but what can I have 2 methods with the same signature but not the same constraint on type ?
06/02/08 @ 09:43
Comment from: Fabrice [Visitor] · http://weblogs.asp.net/fmarguerie
No you can't.
06/02/08 @ 15:03
Comment from: Julien [Visitor] · http://www.thedotnetfrog.fr
Even if you can't have 2 methods with the same signature but different constraints, you can work around that in several ways. A very naive (and bad) implementation would be:

public void MyFunction(T item) where T : class
{
if(item.GetType() == typeof(MyClass))
{
// call another method
}
}


However, I fail to see why you would do a cast in a generic function, the whole point of generics is to avoid casting.

Do you have a specific scenario in mind?
06/05/08 @ 08:04
Comment from: Nicolas Penin [Member] Email · http://dragon-angel.fr
Sure, sometimes, if a class implements a specific interface, you need to do more tasks for this class.
Therefore, you'll have :
public void MyFunction(T item) where T : class
{
//I favour the is keyword to have more flexsibility than testing type itself
if(item is MyInterface)
{
//Do action in this case
}
//Do action for item anyway
}
06/05/08 @ 08:38
Comment from: Julien [Visitor] · http://www.thedotnetfrog.com
The problem with such an implementation is that you'll have different behaviours depending on the given type. You'll also need to modify your generic class if you want to use it with new types to add a new if/elseif statement.
Therefore, someone using that class will need to know the internals to understand what's going on precisely, which breaks a few best practices.
It doesn't seem to me that it's a good usage of generics which, by definition, are supposed to be generics :-).
06/05/08 @ 14:40
Comment from: Nicolas Penin [Member] Email · http://dragon-angel.fr
Actually, when I used it, I did it because I was using dynamic proxies, which I knew they where implementing this interface. This allowed me to know if my item was a dynamic proxy or not. My dynamic proxy has an information I need, but the newly created object don't, and in this case, I need to build it.
06/05/08 @ 14:47

Comments are closed for this post.