covariance | 易学教程

Why the concept of “Covariance” and “Contravariance” are applicable while implementing the methods of an interface?

阅读更多关于 Why the concept of “Covariance” and “Contravariance” are applicable while implementing the methods of an interface?

问题 The use case is some what like this: public class SomeClass : ICloneable { // Some Code // Implementing interface method public object Clone() { // Some Clonning Code } } Now my question is Why is it not possible to use "SomeClass(As it is derived from object)" as a return type of Clone() method if we consider the Funda's of Covariance and Contravariance ? Can somebody explain me the reason behind this implementation of Microsoft ???? 回答1: A non-broken implementation of interface

Generic Class Covariance

阅读更多关于 Generic Class Covariance

问题 Is it possible to make the following code compile in C#? I do compile similar in Java. public interface IInterface { ... } public class Class1 : IInterface { ... } public abstract class Base<T> where T : IInterface { ... } public class Class2<T> : Base<T> where T : IInterface { ... } . . . public SomeMethod() { List<Base<IInterface>> list = new List<Base<IInterface>>(); Class2<Class1> item = new Class2<Class1>(); list.Add(item); // Compile error here } 回答1: No, that is not legal in C#. C# 4

Covariant return type and type conversion

阅读更多关于 Covariant return type and type conversion

问题 s->duplicate() returns an object of type Box* , but I'm getting an error initializing it with Box* . It looks like it's being converted back to Shape* . What is the point of having covariant return types if it's converted back to the base class pointer?: struct Shape { virtual Shape* duplicate() { return new Shape; } }; struct Box : Shape { virtual Box* duplicate() { return new Box; } }; int main() { Shape* s = new Box; Box* b = s->duplicate(); } Error: main.cpp:22:12: error: cannot

Why was IEnumerable<T> made covariant in C# 4?

阅读更多关于 Why was IEnumerable made covariant in C# 4?

In earlier versions of C# IEnumerable was defined like this: public interface IEnumerable<T> : IEnumerable Since C# 4 the definition is: public interface IEnumerable<out T> : IEnumerable Is it just to make the annoying casts in LINQ expressions go away? Won't this introduce the same problems like with string[] <: object[] (broken array variance) in C#? How was the addition of the covariance done from a compatibility point of view? Will earlier code still work on later versions of .NET or is recompilation necessary here? What about the other way around? Was previous code using this interface

Why is parameter in contravariant position?

阅读更多关于 Why is parameter in contravariant position?

I'm trying to use a covariant type parameter inside a trait to construct a case-class like so: trait MyTrait[+T] { private case class MyClass(c: T) } compiler says: error: covariant type T occurs in contravariant position in type T of value c I then tried the following but it also didn't work: trait MyTrait[+T] { private case class MyClass[U <: T](c: U) } the error this time is: error: covariant type T occurs in contravariant position in type >: Nothing <: T of type U Could somebody explain why the T is in a covariant position here and suggest a solution for this problem? Thx! This is a

.NET 4.0 Covariance

阅读更多关于 .NET 4.0 Covariance

问题 In response to another question I have tried to do the following. I don't think I interpreted that question correctly, but I do wonder if the below is possible somehow (my attempts have failed) and if not why not: public class MyBaseClass { } public class MyClass : MyBaseClass { } public class B<T> { } public class A<T> : B<T> { } static void Main(string[] args) { // Does not compile B<MyBaseClass> myVar = new A<MyClass>(); } I thought this might be made to work using a generic interface with

Why is Task<T> not co-variant?

阅读更多关于 Why is Task not co-variant?

class ResultBase {} class Result : ResultBase {} Task<ResultBase> GetResult() { return Task.FromResult(new Result()); } The compiler tells me that it cannot implicitly convert Task<Result> to Task<ResultBase> . Can someone explain why this is? I would have expected co-variance to enable me to write the code in this way. tacos_tacos_tacos According to someone who may be in the know ... The justification is that the advantage of covariance is outweighed by the disadvantage of clutter (i.e. everyone would have to make a decision about whether to use Task or ITask in every single place in their

Difference between covariance and upcasting

阅读更多关于 Difference between covariance and upcasting

问题 What is the difference between covariance and upcasting, or, more specifically, why are they given different names? I've seen the following example referred to as 'upcasting': string s = "hello"; object o = s; //upcast to 'string' to 'object' Whereas, the following I have seen called 'covariance': string[] s = new string[100]; object[] o = s; IEnumerable<string> ies = new List<string>(); IEnumerable<object> ieo = ies; Now, to my untrained eye, covariance seems to be the same as upcasting,

Parameter type covariance in specializations

阅读更多关于 Parameter type covariance in specializations

问题 tl;dr What strategies exist to overcome parameter type invariance for specializations, in a language ( PHP ) without support for generics? Note: I wish I could say my understanding of type theory/safety/variance/etc., was more complete; I'm no CS major. Situation You've got an abstract class, Consumer , that you'd like to extend. Consumer declares an abstract method consume(Argument $argument) which needs a definition. Shouldn't be a problem. Problem Your specialized Consumer , called

Why are Arrays invariant, but Lists covariant?

阅读更多关于 Why are Arrays invariant, but Lists covariant?

E.g. why does val list:List[Any] = List[Int](1,2,3) work, but val arr:Array[Any] = Array[Int](1,2,3) fails (because arrays are invariant). What is the desired effect behind this design decision? Because it would break type-safety otherwise. If not, you would be able to do something like this: val arr:Array[Int] = Array[Int](1,2,3) val arr2:Array[Any] = arr arr2(0) = 2.54 and the compiler cant catch it. On the other hand, lists are immutable, so you can't add something that is not Int This is because lists are immutable and arrays are mutable. Yuhuan Jiang The difference is that List s are