I would like to define a generic library containing generic elements :
public interface ILibrary<T>
My generic elements are defined like this :
interface ILibElement<T, IVersion<T>>
I would like to add the constraint saying that elements in the Library must implement ILibElement. So I thought I could change my definition of the ILibrary like this :
public interface ILibrary<T> where T : ILibElement<T, IVersion<T>>
But I must add type parameters.
So I thought doing something like :
public interface ILibrary<ILibElement<T, IVersion<T>>>
But T is undefined.
I could not find the right syntax. How could I express such a constraint ?
I believe you're just looking to do this:
where T : ILibElement<T, IVersion<T>>
since ILibElement is expressed as ILibElement<T, IVersion<T>> you just need to specifically implement that interface with the T that you're implementing.
I think you can try a logic like this
public interface ILibrary<T,V> where T:ILiBelement<T,V> where T:ILiBelement<T,V>
where V:IVersion<V>
{
}
interface ILiBelement<T,V> where V:IVersion<T>
{
}
interface IVersion<T>
{
}
hope this help
Generic type parameters must be specified as identifiers; the constraints may use more complex nested formulations, but the parameters themselves must not. If one wanted a generic method which took a parameter of some type Nullable<T>, one wouldn't specify it as:
void ThisWontWork<Nullable<T>>(T it) where T:struct {...}
but instead as:
void ThisWillWork<T>(Nullable<T> it) where T:struct {...}
If your collection may be holding further-qualified generic things which will all be of one type, you may wish to add that type as a type parameter for your collection:
class ListOfLists<T,U> where T:IList<U>
If your collection will be holding things that implement a generic interface with a variety of generic types, but you'll only need to use members which do not involve such types, then you should if possible have the members which don't care about the generic type segregated into their own interface, which could be inherited by the full generic. For example, although Microsoft didn't design their IDictionary this way, it could have been defined as something like (in part:)
interface ICheckIfContained
{ bool Contains(object it); }
interface ICheckIfContained<in T> : ICheckIfContained
{ bool Contains(T it); }
interface IDictionary<in TKey, out TValue> : ICheckIfContained<TKey> ...
If one wants to hold a collection of references to dictionaries purely for the purpose of scanning the keys keys in them, without regard for what those keys would map to, a generic parameter constrained to ICheckIfContained could serve such a purpose.
Related
I want to create a List<System.Type> listOfTypesOfGlasses , where Type must implement a specific interface IGlass , so I could load it with Types of glasses.
Is there a way to enforce in compile time this constraint(must implement IGlass) ?
Implement a method/class that hides the list.
class YourClass {
// intentionally incomplete
private List<Type> listOfTypesOfGlasses;
public void AddToList<T>() : where T: IGlass
{
listOfTypesOfGlasses.Add(typeof(T));
}
}
Edit: below is the original answer here assuming that Type meant a placeholder, not System.Type.
All you should need to do is List<IGlass>.
or
You should write your own wrapper class around List<T> that has the constraint.
or
Subclass List<T> and put the generic constraint on it - however this practice is discouraged.
No - typeof(IGlass) and typeof(Glass) are both Type objects - not different classes that can be filtered in a generic constraint. There's no generic restriction that works off of the values stored. If you want to store instances of types that all implement IGlass that's possible, but you can;t filter the actual Type objects that can be stored.
I'm currently wondering when to use which type of a generic interface definition. Let's take this as an example:
// (I)
public interface IStorage<T>
where T: class, new()
{
void SaveTo(string fileName, T what);
T LoadFrom(string fileName);
}
// (II)
public interface IStorage
{
void SaveTo<T>(string fileName, T what)
where T: class;
T LoadFrom(string fileName)
where T: class, new();
}
From my point of view, I would say that:
I will use (I) if the methods within the interface (or conrete type) depend on each other and operate on the same internal data. Therefor I have IList in my mind: All methods within IList are operating on the same data. It makes sense to have one instance per conrete type.
I will use (II) if the methods within the interface (or concrete type) are not depending on each other (so they don't operate on same internal data). That means, I could have one instance and use it for different concrete types.
So, what do you think? Is there a best practice? Other thoughts on this?
Consider the difference in logical meaning of the association.
A class implementing the generic interface Interface<Type> will be logically associated with that Type. And all the methods of that class which refer to Type will also be associated with it.
This might lend itself well to an interface representing a Builder (pattern).
A class with generic type methods (Type doSomething<Type>) will have methods logically associated with the specified type when called. Different methods may expect different generic types to be provided.
This might lend itself well to an interface representing a Factory (pattern).
In Java I can easily write:
public interface MyInterface<T extends Object>
and then have a method which determine the T at runtime like:
public MyInterface<?> DetermineObjectAtRuntime()
But in C# where <?> is not available and I need to call the method with type; which means I need to know the type before hand.
Is it possible to return generics type from non-generic method?
If not, how can I work out the type to call such generic method if I have an object instance with that type?
For people who are not sure what this is for - I have a set of data structures which are using different enums as field indexers. All the messages extends from a common generic interface with that enum as type variable. Now I need to work out a method which deserialize all different types of messages from a byte[] array.
In C#, which does not have type erasure, there are several ways to work around not knowing a type argument at compile-time:
Non-generic subset: If it happens to be the case that the methods of MyInterface<T> that you need don't involve T, then you can extract that portion of the interface into a base interface and return the base interface instead.
Pro: No runtime type shenanigans.
Con: Modifies the type (moving methods to a new base interface), breaking binary compatibility.
Type checking wrapper: Make a RuntimeTypeCheckedMyInterface<T> class that implements MyInterface<object> by delegating to a MyInterface<T> after type checking. Have the method return a MyInterface<object>, created by wrapping the MyInterface<whatever> inside a RuntimeTypeCheckedMyInterface.
Pro: Works with any existing interface type, without modifying it.
Con: Introduces "does T=object really mean object, or does it mean unknown type"? ambiguity.
Manual type erasure: Make a variant of MyInterface<T> that doesn't have a T like MyInterfaceOfUnknownType. Make MyInterface<T> inherit from MyInterfaceOfUnknownType. Have your method return MyInterfaceOfUnknownType.
Pro: Acts basically identical to Java, with MyInterfaceOfUnknownType = MyInterface<?>.
Con: Pollutes MyInterface<T> with non-generic methods. When the methods differ only by return type you have to disambiguate with a name change. Modifies the type (breaking source and binary compatibility).
Screw the types: Have the method return object or dynamic. Cast conditionally and appropriately.
Pro: Initially easy to do.
Con: Harder to maintain.
"But in C# where '< ? >' is not available and I need to call the method with type; which means I need to know the type before hand."
You can use dynamic instead of <T> for example:
dynamic Foo (dynamic Input) {return Input;}
The compiler determines the type at runtime.
In C#, you can have generic methods:
class Foo<X>
{
public T DoSomethingFunky<T>( ... )
{
...
}
}
But there's no way to have a wildcard type — a big fail in C#. It would be very useful in a lot of situations where you that it is a Widget<T> but you don't care about the particulars of T.
For instance, WCF throws FaultException<T>, where the various flavors of T are service specific. There's no way to catch something like FaultException<*> without simply catching the base Exception class and using reflection to inspect the caught exception to see if it's an interesting T. This prevents handling service faults in a generic way.
I believe the reason is that a concrete generic class (Widget<int>) are not really subtypes of the generic class (Widget<T>) it "inherits" from. The generic class is simply used as a template to compile a new specific class.
The one thing you could do, is have your generic template (Widget<T>) inherit from a non-generic base class (Widget) and have your method return that:
class AbstractWidget { ... }
class Widget<T> : AbstractWidget { ... }
.
.
.
public Widget GetGeneric Widget()
{
/* flavor determinated at runtime */
}
It's incumbent upon the caller to decide what to do with its Widget.
Another way is to add an extension
public static class MyExtensions
{
public static T As<T>(this object obj)
{
return (T)obj;
}
}
the above will provide you a .As() method
i understand what they are, I'm just wondering when is the best time to use them.
My first thought was - when we are building a (static) utility class which should perform certain operations on different data types.
Ergo, it is a good practice to use generic methods to avoid numerous overloads of a certain method? Please comment on this.
I have a small example class. It's just for the sake of an example.
public static class Math<T> where T : operator +, operator -
{
public static T Add(T a1, T a2)
{
return a1+a2;
}
public static T Subtract(T a1, T a2)
{
return a1 - a2;
}
}
Would this be a good usage of generic classes and methods, e.g I wish to add and subtract ints, doubles.. etc.. with the minimum amount of code ?
Why won't this compile? I've tried this as well as modifying the class signature:
public static class Math<T> where T : struct
I understand that I must specify whether the Type parameter is of reference or of value type.
I did that by specifying that T must be constrained as a value type, so why am I still getting error that the operator + and/or - cannot be applied to T (which should specifically be a value type)
No this wouldn't be a good use. Generics are to provide type-safe data structures without knowing the type. Generic constraints allow you to specify some semantics about the type, such as implementing an interface, having a default constructor, or being a class or struct.
Please see these MSDN articles:
An Introduction to C# Generics
Constraints on Type Parameters
.
It won't compile because the operator + parts are not valid constraints.
Being a value type does not infer operators such as + or -, it only infers value-type semantics (inherits object, is a value type, cannot be null, has a default constructor).
Generic Constraints
Generic constraints help the compiler give you more from your T. An unconstrained generic can only be proven to be object, so you only get access to object members on the argument.
If you state: public void Foo<T>() where T : new()
The compiler can prove that your type has a default public parameterless constructor. This is the purpose of constraints, it forces the types that can be party to the generic to conform to a contract.
There are various constraints, but as you have found there are some limitations. Interestingly, there are limitations in C# that do not exist in IL, as explored by Jon Skeet in his Unconstrained Melody library that exposes enum constraints to C#.
As written by others the operator+ isn't a valid constraint. If what you want is to make some generic math, you can use something like:
public static class Add<T>
{
public static readonly Func<T, T, T> Do;
static Add()
{
var par1 = Expression.Parameter(typeof(T));
var par2 = Expression.Parameter(typeof(T));
var add = Expression.Add(par1, par2);
Do = Expression.Lambda<Func<T, T, T>>(add, par1, par2).Compile();
}
}
public static class Math<T>
{
public static T Add(T a1, T a2)
{
return Add<T>.Do(a1, a2);
}
This will create and compile an Expression that does the operation and then cache it in a generic static class.
Sadly with this method you lose the static checking of you compiler (you could do something like:
object res = Math<object>.Add(new object(), new object());
and it would compile correctly. At runtime it would explode.)
In general you can't make a constraint asking for a specific method (static or non-static) or a specific property to be present (operators are like static methods) (with a single exception: the new() constraint that asks for a public parameterless constructor). What you can ask is for an interface to be implemented, or for a base class to be present, or for the generic parameter to be a class or a struct (where the two must be meant as "reference type" and "value type", and not simply as class and struct). Sadly there are no interfaces IAddable, ISubtractable, ... and even if you built them, int, double... wouldn't implement them, and to make it worse, in .NET you can't have generic specializations (a trick of C++ where you define a generic Math<T> and then you define special "cases" explicitly, like Math<int>, Math<double> and so on)
The obvious use case for generic classes is data structures which can then store any type of data without having to treat it all as instances of object. You probably use these all the time - IList<T>, IDictionary<K, V> etc. It lets you store things where you don't know the type when you're writing the structure while retaining type safety. The trick being that you also don't know anything about the type you're storing so you can't do much with it.
Thus generic constraints, which let you say something is a reference type or a value type, or has a parameterless constructor, or implements an interface. These come in useful when you're writing a generic class which has to do something with instances of the parameterised type. Might seem useless - why not just use an interface type as the parameter type and avoid generics altogether? Because generic constraints can force a parameter to conform to more than one interface - something you can't specify in a normal parameter type. Thus you can write a function:
public static void Frobnicate<T>(T thing)
where T : IList<int>, IDisposable
{
// ...
}
You can also stick a single base class name in there too. This is far, far more flexible than specifying concrete types. Sure you could create an interface which inherits from IList<int> and IDisposable but you can't retrofit all disposable lists of integers that might be out there to implement it.
You could also do it at runtime using reflection to inspect things, but this kind of thing is far better handled by the compiler, IMO.
I'm trying to call a method with a definition similar to the following (simplified to avoid confusion):
public static void Register<T>(T value) where T : BaseClass, IInterface
This works fine so long as I have a class instance that defines both of those values. The problem occurs when I pass a `BaseClass' into a method and then try to use that instance in the above declaration. For example:
public class MyClass
{
public MyClass(BaseClass value)
{
Register(value);
}
}
I can pass and instance of a class that implements both BaseClass and IInterface into the constructor, but when I try to use that value in the Register method I get a compilation error stating:
The type 'BaseClass' cannot be used as type parameter 'T' in the generic type or method 'Register(T)'. There is no implicit reference conversion from 'BaseClass' to 'IInterface'.
If I change the type in the constructor like so:
public class MyClass
{
public MyClass(IInterface value)
{
Register(value);
}
}
I get an error stating:
The type 'IInterface' cannot be used as type parameter 'T' in the generic type or method 'Register(T)'. There is no implicit reference conversion from 'IInterface' to 'BaseClass'.
This seems like a bit of a catch-22. Is there a way that I can define the parameter to indicate that it must implement both BaseClass and IInterface?
As I was writing the question I came up with the answer and thought I would post it instead of deleting the question.
I just need to redefine the class:
public class MyClass<T> where T : BaseClass, IInterface
{
public MyClass(T value)
{
Register(value);
}
}
The solution given by Matt is an easy answer for situations where it is not necessary to store the passed-in object in a field or collection. If you need to persist the passed-in object, things get much harder. It's easy for a SomeClass<T> where T meets multiple constraints, to store items of class T and pass them as generics to routines with such constraints, but if a class has a method SomeMethod<TParam>(TParam thing) where TParam:IFoo,BaseBar, it won't have any field of type TParam. It could store thing into a field of type IFoo or BaseBar, but unless BaseBar implements IFoo, or all passed-in instances are going to derive from one particular BaseBar derivative which implements IFoo, there's no way to specify that a field's type will meet both constraints (if every instance does derive from one particular BaseBar derivative which implements IFoo, one could simply use that type as a single constraint, or for that matter not bother with generics at all—just use that as the parameter type).
There are ways of getting around these issues, either using Reflection, an interface pattern I call ISelf<T>, or some tricky nested callback interfaces. In some cases, though, it may be better to provide alternatives to methods that take double-constrained parameters (have the methods take a parameter of one constraint type, cast it to the other type, and accept the lack of compile-time safety).