contravariance

问题 I'm having some problems setting up a command handling architecture. I want to be able to create a number of different commands derived from ICommand; then, create a number of different command handlers derived from ICommandHandler; Here's the interface and classes I have begun to define: interface ICommand {} class CreateItemCommand : ICommand {} interface ICommandHandler<TCommand> where TCommand : ICommand { void Handle(TCommand command); } class CreateItemCommandHandler : ICommandHandler

问题 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

问题 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

问题 This question already has answers here : Closed 8 years ago . Possible Duplicate: Covariance and Contravariance on the same type argument You can declare a generic type parameter as covariant by using the out keyword: interface ICovariant<out R> You can declare a generic type parameter as contravariant by using the in keyword: interface IContravariant<in R> And you can also support both for different type parameters: interface IVariant<out R, in A> So why can't you suport both for a single

问题 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

问题 Is there any reason why Scala's Ordering trait is not contravariant? A motivating example follows. Suppose I want to perform an ordered insert. I may have a function with the signature def insert[A, B >: A](list: List[A], item: A)(implicit ord: Ordering[B]): List[A] Here, I have an Ordering which accepts super types of type A . I imagine this is useful when you're dealing with case classes . For example: abstract class CodeTree case class Fork(left: CodeTree, right: CodeTree, chars: List[Char

问题 In the Nomicon's section about subtyping, it says contravariance is available for a function pointer type. However, I can't find any good examples of this. I tried to code a struct with a function pointer, but the contravariance doesn't seem to work. What is a code example of this? 回答1: Rust's notion of subtyping only applies to lifetimes. Searching for the term "contra" on the page you linked has numerous relevant paragraphs: Actually witnessing contravariance is quite difficult in Rust,

问题 I am not sure if this is a Covariance and Contravariance issue but I cannot get this working. Here is the code: public interface IDto { } public class PaginatedDto<TDto> where TDto : IDto { public int PageIndex { get; set; } public int PageSize { get; set; } public int TotalCount { get; set; } public int TotalPageCount { get; set; } public bool HasNextPage { get; set; } public bool HasPreviousPage { get; set; } public IEnumerable<TDto> Dtos { get; set; } } public class PersonDto : IDto {

问题 The C# spec states that an argument type cannot be both covariant and contravariant at the same time. This is apparent when creating a covariant or contravariant interface you decorate your type parameters with "out" or "in" respectively. There is not option that allows both at the same time ("outin"). Is this limitation simply a language specific constraint or are there deeper, more fundamental reasons based in category theory that would make you not want your type to be both covariant and

问题 The C# spec states that an argument type cannot be both covariant and contravariant at the same time. This is apparent when creating a covariant or contravariant interface you decorate your type parameters with "out" or "in" respectively. There is not option that allows both at the same time ("outin"). Is this limitation simply a language specific constraint or are there deeper, more fundamental reasons based in category theory that would make you not want your type to be both covariant and