contravariance

Covariance and Contravariance in C#

由 青春壹個敷衍的年華 提交于 2019-12-05 01:14:49
I will start by saying that I am Java developer learning to program in C#. As such I do comparisons of what I know with what I am learning. I have been playing with C# generics for a few hours now, and I have been able to reproduce the same things I know in Java in C#, with the exception of a couple of examples using covariance and contravariance. The book I am reading is not very good in the subject. I will certainly seek more info on the web, but while I do that, perhaps you can help me find a C# implementation for the following Java code. An example is worth a thousand words, and I was

Covariance and Contravariance - Just different mechanisms for invoking guaranteed base class behavior?

由 末鹿安然 提交于 2019-12-04 21:21:00
问题 I'm having a struggle understanding these two concepts. But I think after many videos and SO QA's, I have it distilled down to its simplest form: Covariant - Assumes a sub-type can do what its base-type does. Contravariant - Assumes you can treat a sub-type the same way you would treat its base-type. Supposing these three classes: class Animal { void Live(Animal animal) { //born! } void Die(Animal animal) { //dead! } } class Cat : Animal { } class Dog : Animal { } Covariant Any animal can do

How to implement template class covariance in C++?

由 六月ゝ 毕业季﹏ 提交于 2019-12-04 16:48:17
Is it possible to implement a class template in such a way that one object could be casted to another if their template arguments are related? Here is an exaple to show the idea (of course it will not compile): struct Base {}; struct Derived : Base {}; template <typename T> class Foo { virtual ~Foo() {} virtual T* some_function() = 0; }; Foo<Derived>* derived = ...; Foo<Base>* base = derived; The additional problem here is that Foo is an abstract class used as an interface containing functions returning T& and T*, so I can't implement a template copy constructor. I'm writing a universal

Implementing a method inside a Scala parameterized class with a covariant type

由 匆匆过客 提交于 2019-12-04 16:08:46
I've read a few tutorials including the main Scala documentation regarding method signatures of covariant types. Suppose I have the following abstract class: abstract class List[+A] { def head: A def tail: List[A] def isEmpty: Boolean def add[B >: A](element: B): List[B] protected def printElements: String override def toString: String = "[" + printElements + "]" } My question concerns the signature of the add() method. Why is it necessary to declare it that way? We are passing in a parameter that is a supertype of A. What problem does this solve? I'm trying to understand this on an intuitive

Covariance vs. contravariance with respect to class inheritance

由 偶尔善良 提交于 2019-12-04 12:28:32
问题 What is the meaning of the concepts 'covariance' and 'contravariance'? Given 2 classes, Animal and Elephant (which inherits from Animal ), my understanding is that you would get a run-time errors if you try and put an Elephant into an array of Animals, and this happens because Elephant is "bigger" (more specific) than Animal. But could you place an Animal into an array of Elephant, seeing how Elephant is guaranteed to contain the Animal properties? 回答1: You have it backwards. You can add an

MonoTouch and supporting variant generic interfaces

由 那年仲夏 提交于 2019-12-04 06:55:18
The below example compiles fine in regular Mono 2.10.9: namespace covarianttest { public interface ITest<out T> : IEnumerable<T> { } } However when I attempt compile it against MonoTouch 6.0.8 I receive this error: Error CS1961: The covariant type parameter 'T' must be invariantly valid on 'covarianttest.ITest' So am I to assume that MonoTouch doesn't support extending covariant/contravariant generic interfaces yet? If so what is the recommend workaround for this situation in MonoTouch? This actually depend on the compiler (and profile/runtime) not the Mono version. IOW some things might work

Why Liskov Substitution Principle needs the argument to be contravariant?

由 有些话、适合烂在心里 提交于 2019-12-04 04:59:57
One of the rules that Liskov Substitution Principle imposes on method signature in derived class is: Contravariance of method arguments in the subtype. If I understood correctly, it is saying that the derived class's overridding function should allow contravariant arguments(Supertype arguments). But, I could'nt understand the reason behind this rule. Since LSP talks mostly about dynamically binding the types with there subtypes(rather than supertypes) in order to achieve abstraction, so allowing supertypes as the method arguments in derived class is quite confusing to me. My questions are :

Conversion from Func<object,string> to Func<string,string> works but to Func<int,string> fails

由 喜欢而已 提交于 2019-12-04 03:58:16
问题 I have the following code: static Func<object, string> s_objToString = (x) => x.ToString(); static Func<string, string> s_stringToString = s_objToString; //compiles static Func<int, string> s_intToString = s_objToString; //error The second line compiles but the third line fails to compile with error: Cannot implicitly convert type ' System.Func<object,string> ' to ' System.Func<int,string> ' Why is that? I understand that with genetics although string is derived from object a List<string>

Variance rules in C#

由 断了今生、忘了曾经 提交于 2019-12-04 03:09:08
The Exact rules for variance validity are a bit vague and not specific. I'm going to list the rules for what makes a type valid-covariantly, and attach some queries and personal annotations to each of those rules. A type is valid covariantly if it is: 1) a pointer type, or a non-generic type. Pointers and non-generic types are not variant in C#, except for arrays and non-generic delegates. Generic classes, structs and enums are invariant. Am I right here? 2) An array type T[] where T is valid covariantly. So this means that if the element type T of an array T[] is covariant (reference or array

General 'map' function for Scala tuples?

由 橙三吉。 提交于 2019-12-04 02:44:03
I would like to map the elements of a Scala tuple (or triple, ...) using a single function returning type R. The result should be a tuple (or triple, ...) with elements of type R. OK, if the elements of the tuple are from the same type, the mapping is not a problem: scala> implicit def t2mapper[A](t: (A,A)) = new { def map[R](f: A => R) = (f(t._1),f(t._2)) } t2mapper: [A](t: (A, A))java.lang.Object{def map[R](f: (A) => R): (R, R)} scala> (1,2) map (_ + 1) res0: (Int, Int) = (2,3) But is it also possible to make this solution generic, i.e. to map tuples that contain elements of different types
订阅 contravariance