471,305 Members | 1,120 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,305 software developers and data experts.

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

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?
Jun 27 '08 #1
4 1775
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 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
Jun 27 '08 #2
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 <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 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
Jun 27 '08 #3
On Jun 6, 12:53 am, "Rene" <a...@b.comwrote:
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?
Jun 27 '08 #4
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
Jun 27 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

21 posts views Thread by Walter L. Preuninger II | last post: by
3 posts views Thread by Sathyaish | last post: by
8 posts views Thread by Leszek Taratuta | last post: by
4 posts views Thread by =?Utf-8?B?R3JlZw==?= | last post: by
5 posts views Thread by PJ6 | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.