How to determine whether a type implements a generic interface with aself-referential constraint

[Weeble]

I have an interface that looks something like this:
public interface IFoo<Twhere T : IFoo<T{ ... }

Inside a class that looks something like this...
public class Bar<V{ ... }
....I would like to find out if V implements IFoo<V>. However, I can't
do this...
if (typeof(IFoo<V> ).IsAssignableF rom(typeof(V))) { ... }
....because it's circular: the compiler won't let us refer to IFoo<V>
because we don't know if V implements IFoo<V>. The best I can do is
this:

bool implementsInter face = true;
try
{
typeof(IFoo<>). MakeGenericType (typeof(V));
}
catch (ArgumentExcept ion)
{
// Oops! I guess not.
implementsInter face = false;
}

However, I don't get the impression this is the "right" way to do it.
I don't like the idea of catching an ArgumentExcepti on in general. Is
there some other way to do this?

[Jon Skeet [C# MVP]]

On Jun 5, 5:13 pm, Weeble <clockworksa... @gmail.comwrote :

<snip>

However, I don't get the impression this is the "right" way to do it.
I don't like the idea of catching an ArgumentExcepti on in general. Is
there some other way to do this?

You could get all the interfaces that the type implements (potentially
recursively). For each of them, see if the generic type ==
typeof(IFoo<>), and then check the generic type argument to see if
it's typeof(V).

Jon

[Rene]

So working from Jon's idea, perhaps something like the code below would
work?

---------------------------
using System;
using System.Collecti ons.Generic;
using System.Text;

public interface IFoo<Twhere T : IFoo<T>
{
}

class SomeClass : IFoo<SomeClass>
{
}

class Bar<V>
{
public static bool ImplementsInter face()
{
string interfaceName = typeof(IFoo<>). Name;
Type theInterface = typeof(V).GetIn terface(interfa ceName);
if (theInterface != null)
{
Type deff = theInterface.Ge tGenericTypeDef inition();
return (deff == typeof(IFoo<>)) ;
}
else
return false;
}
}

class Program
{
static void Main(string[] args)
{
bool result1 = Bar<SomeClass>. ImplementsInter face();
Console.WriteLi ne(result1.ToSt ring());

bool result2 = Bar<string>.Imp lementsInterfac e();
Console.WriteLi ne(result2.ToSt ring());

Console.Read();
}
}
---------------------------

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:2e******** *************** ***********@i76 g2000hsf.google groups.com...

On Jun 5, 5:13 pm, Weeble <clockworksa... @gmail.comwrote :

<snip>

>However, I don't get the impression this is the "right" way to do it.
I don't like the idea of catching an ArgumentExcepti on in general. Is
there some other way to do this?

You could get all the interfaces that the type implements (potentially
recursively). For each of them, see if the generic type ==
typeof(IFoo<>), and then check the generic type argument to see if
it's typeof(V).

Jon

[Weeble]

On Jun 6, 12:53 am, "Rene" <[e-mail] e:

So working from Jon's idea, perhaps something like the code below would
work?

[snip]

That's great, thank you both! I think to be safe I'd still need to
check the generic type argument, otherwise it could break like this:

class CheatClass : SomeClass { }

Which gives {Bar<CheatClass >.ImplementsInt erface()==True} , which isn't
quite what I want to check. But it's clear how to handle that, so
thanks!

Of course, now there's the question of whether there's a better way
than wanton use of reflection to get out of the generic tangle that
resulted in this. Sadly it's not easy to show an isolated example, so
I think I'll leave it for another time. In general terms, would people
say that *sometimes* it's better just to suffer a bit of typecasting
rather than try to preserve types with complex application of
generics, or is there *always* a good generic solution that guarantees
type-safety at compile-time?

[Jon Skeet [C# MVP]]

On Jun 6, 3:14 pm, Weeble <clockworksa... @gmail.comwrote :

<snip>

Of course, now there's the question of whether there's a better way
than wanton use of reflection to get out of the generic tangle that
resulted in this. Sadly it's not easy to show an isolated example, so
I think I'll leave it for another time. In general terms, would people
say that *sometimes* it's better just to suffer a bit of typecasting
rather than try to preserve types with complex application of
generics, or is there *always* a good generic solution that guarantees
type-safety at compile-time?

The former. Things will improve slightly if/when C# 4 includes generic
variance, but it'll never go away entirely. It's always worth *trying*
to see if there's a generic solution to solve the problem, but it
won't always happen.

Jon