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>).IsAssignableFrom(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 implementsInterface = true;
try
{
typeof(IFoo<>).MakeGenericType(typeof(V));
}
catch (ArgumentException)
{
// Oops! I guess not.
implementsInterface = 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 ArgumentException in general. Is
there some other way to do this?

[Jon Skeet [C# MVP]]

On Jun 5, 5:13 pm, Weeble <[e-mail]:

<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 ArgumentException 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.Collections.Generic;
using System.Text;

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

class SomeClass : IFoo<SomeClass>
{
}

class Bar<V>
{
public static bool ImplementsInterface()
{
string interfaceName = typeof(IFoo<>).Name;
Type theInterface = typeof(V).GetInterface(interfaceName);
if (theInterface != null)
{
Type deff = theInterface.GetGenericTypeDefinition();
return (deff == typeof(IFoo<>));
}
else
return false;
}
}

class Program
{
static void Main(string[] args)
{
bool result1 = Bar<SomeClass>.ImplementsInterface();
Console.WriteLine(result1.ToString());

bool result2 = Bar<string>.ImplementsInterface();
Console.WriteLine(result2.ToString());

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

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:2e**********************************@i76g2000 hsf.googlegroups.com...

On Jun 5, 5:13 pm, Weeble <[e-mail]:

<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 ArgumentException 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]:

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>.ImplementsInterface()==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 <[e-mail]:

<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