Suppose I have defined two unrelated types and two extension methods with the same signature but different type filters:
public class Foo {}
public class Bar {}
Actually, the general goal (from your description and my practice and view) is more concise representation for sets of “similar” extension for classes. The “similarity” partially may be that names of these classes are quite long multipart camel-case identifiers which even do not always differ in the first part.
So, using generics is good only in case of class inheritance. For non-inheritable classes solution is using short class aliases.
public class Foo0987654321 { }
public class SucFoo0987654321 : Foo0987654321 { }
public class Bar1234567890 { }
namespace NET_Site
{
using B = Bar1234567890;
public static class BarExtensions
{
public static B Frob(this B bar)
{
// ...
return bar;
}
}
}
namespace NET_Site
{
using TFoo = Foo0987654321;
public static class FooExtensions
{
public static TF Frob<TF>(this TF foo)
where TF : TFoo
{
// ...
return foo;
}
public static TF Brob<TF>(this TF foo)
where TF : TFoo
{
// ...
return foo;
}
}
}
new SucFoo0987654321()
.Frob()
.Brob();
The constraint of a generic type parameter is not part of the method's signature. These two methods are essentially the same from a resolution point of view; when the compiler tries to resolve the call it sees two valid methods and it has no way to choose the better one, therefore the call is flagged as ambiguous.
You can read more about this issue here.