Search Results

Search found 42 results on 2 pages for 'contravariance'.

Page 1/2 | 1 2  | Next Page >

  • Covariance and Contravariance in C#

    - by edalorzo
    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 hoping that by looking a good code sample I will be able to assimilate this more rapidly. Covariance In Java I can do something like this: public static double sum(List<? extends Number> numbers) { double summation = 0.0; for(Number number : numbers){ summation += number.doubleValue(); } return summation; } I can use this code as follows: List<Integer> myInts = asList(1,2,3,4,5); List<Double> myDoubles = asList(3.14, 5.5, 78.9); List<Long> myLongs = asList(1L, 2L, 3L); double result = 0.0; result = sum(myInts); result = sum(myDoubles) result = sum(myLongs); Now I did discover that C# supports covariance/contravariance only on interfaces and as long as they have been explicitly declared to do so (out). I think I was not able to reproduce this case, because I could not find a common ancestor of all numbers, but I believe that I could have used IEnumerable to implement such thing if a common ancestor exists. Since IEnumerable is a covariant type. Right? Any thoughts on how to implement the list above? Just point me into the right direction. Is there any common ancestor of all numeric types? Contravariance The contravariance example I tried was the following. In Java I can do this to copy one list into another. public static void copy(List<? extends Number> source, List<? super Number> destiny){ for(Number number : source) { destiny.add(number); } } Then I could use it with contravariant types as follows: List<Object> anything = new ArrayList<Object>(); List<Integer> myInts = asList(1,2,3,4,5); copy(myInts, anything); My basic problem, trying to implement this in C# is that I could not find an interface that was both covariant and contravariant at the same time, as it is case of List in my example above. Maybe it can be done with two different interface in C#. Any thoughts on how to implement this? Thank you very much to everyone for any answers you can contribute. I am pretty sure I will learn a lot from any example you can provide.

    Read the article

  • Covariance and Contravariance type inference in C# 4.0

    - by devoured elysium
    When we define our interfaces in C# 4.0, we are allowed to mark each of the generic parameters as in or out. If we try to set a generic parameter as out and that'd lead to a problem, the compiler raises an error, not allowing us to do that. Question: If the compiler has ways of inferring what are valid uses for both covariance (out) and contravariance(in), why do we have to mark interfaces as such? Wouldn't it be enough to just let us define the interfaces as we always did, and when we tried to use them in our client code, raise an error if we tried to use them in an un-safe way? Example: interface MyInterface<out T> { T abracadabra(); } //works OK interface MyInterface2<in T> { T abracadabra(); } //compiler raises an error. //This makes me think that the compiler is cappable //of understanding what situations might generate //run-time problems and then prohibits them. Also, isn't it what Java does in the same situation? From what I recall, you just do something like IMyInterface<? extends whatever> myInterface; //covariance IMyInterface<? super whatever> myInterface2; //contravariance Or am I mixing things? Thanks

    Read the article

  • Covariance and Contravariance inference in C# 4.0

    - by devoured elysium
    When we define our interfaces in C# 4.0, we are allowed to mark each of the generic parameters as in or out. If we try to set a generic parameter as out and that'd lead to a problem, the compiler raises an error, not allowing us to do that. Question: If the compiler has ways of inferring what are valid uses for both covariance (out) and contravariance(in), why do we have to mark interfaces as such? Wouldn't it be enough to just let us define the interfaces as we always did, and when we tried to use them in our client code, raise an error if we tried to use them in an un-safe way? Example: interface MyInterface<out T> { T abracadabra(); } //works OK interface MyInterface2<in T> { T abracadabra(); } //compiler raises an error. //This makes me think that the compiler is cappable //of understanding what situations might generate //run-time problems and then prohibits them. Also, isn't it what Java does in the same situation? From what I recall, you just do something like IMyInterface<? extends whatever> myInterface; //covariance IMyInterface<? super whatever> myInterface2; //contravariance Or am I mixing things? Thanks

    Read the article

  • Covariance vs. contravariance

    - by alexmac
    What are the concepts of covariance and contravariance? Given 2 classes, Animal and Elephant (which inherits from Animal), my understanding is that you get runtime errors in .NET if you try and put an Elephant into an array of Animal, which happens because Elephant is "bigger" (more specific) than Animal. But could you assign Animal to an array of Elephants as Elephant is guaranteed to contain the Animal properties?

    Read the article

  • Example of contravariance

    - by Misha
    I am thinking of the following example to illustrate why contravariance is useful. Let's consider a GUI framework with Widgets, Events, and Event Listeners. abstract class Event; class KeyEvent extends Event class MouseEvent extends Event trait EventListener[-Event] { def listen(e:Event) } Let Widgets define the following methods: def addKeyEventListener(listener:EventListener[KeyEvent]) def addMouseEventListener(listener:EventListener[MouseEvent]) These methods accept only "specific" event listeners, which is fine. However I would like to define also "kitchen-sink" listeners, which listen to all events, and pass such listeners to the "add listener" methods above. For instance, I would like to define LogEventListener to log all incoming events class LogEventListener extends EventListener[Event] { def listen(e:Event) { log(event) } } Since the trait EventListener is contravariant in Event we can pass LogEventListener to all those "add listener" methods without losing their type safety. Does it make sense ?

    Read the article

  • Can't contravariance be solved with interfaces?

    - by Sir Psycho
    Hi, I'm at the point where I'm starting to grasp contravariance, although I'm trying to work out what the advantage is when an interface can be used instead. Obviously I'm missing something. Here is the c#4 example class Dog : Animal { public Dog(string name) : base(name) { } } class Animal { string _name; public Animal(string name) { _name = name; } public void Walk() { Console.WriteLine(_name + " is walking"); } } Action<Animal> MakeItMove = (ani) => { ani.Walk(); }; Action<Dog> MakeItWalk = MakeItMove; MakeItWalk(new Dog("Sandy")); Same example which works in earlier versions on c# class Dog : Animal { public Dog(string name) : base(name) { } } class Animal : IAnimal { string _name; public Animal(string name) { _name = name; } public void Walk() { Console.WriteLine(_name + " is walking"); } } interface IAnimal { void Walk(); } Action<IAnimal> MakeItMove = (ani) => { ani.Walk(); }; Action<IAnimal> MakeItWalk = MakeItMove; MakeItWalk(new Dog("Sandy")); These may not be the best examples, but I still can't seem to 'get it'. Is the in keywork defined on the action delegate simply a short hand syntax way like lamda is to delegates?

    Read the article

  • C# 4.0: Covariance And Contravariance In Generics

    - by Paulo Morgado
    C# 4.0 (and .NET 4.0) introduced covariance and contravariance to generic interfaces and delegates. But what is this variance thing? According to Wikipedia, in multilinear algebra and tensor analysis, covariance and contravariance describe how the quantitative description of certain geometrical or physical entities changes when passing from one coordinate system to another.(*) But what does this have to do with C# or .NET? In type theory, a the type T is greater (>) than type S if S is a subtype (derives from) T, which means that there is a quantitative description for types in a type hierarchy. So, how does covariance and contravariance apply to C# (and .NET) generic types? In C# (and .NET), variance applies to generic type parameters and not to the resulting generic type. A generic type parameter is: covariant if the ordering of the generic types follows the ordering of the generic type parameters: Generic<T> = Generic<S> for T = S. contravariant if the ordering of the generic types is reversed from the ordering of the generic type parameters: Generic<T> = Generic<S> for T = S. invariant if neither of the above apply. If this definition is applied to arrays, we can see that arrays have always been covariant because this is valid code: object[] objectArray = new string[] { "string 1", "string 2" }; objectArray[0] = "string 3"; objectArray[1] = new object(); However, when we try to run this code, the second assignment will throw an ArrayTypeMismatchException. Although the compiler was fooled into thinking this was valid code because an object is being assigned to an element of an array of object, at run time, there is always a type check to guarantee that the runtime type of the definition of the elements of the array is greater or equal to the instance being assigned to the element. In the above example, because the runtime type of the array is array of string, the first assignment of array elements is valid because string = string and the second is invalid because string = object. This leads to the conclusion that, although arrays have always been covariant, they are not safely covariant – code that compiles is not guaranteed to run without errors. In C#, the way to define that a generic type parameter as covariant is using the out generic modifier: public interface IEnumerable<out T> { IEnumerator<T> GetEnumerator(); } public interface IEnumerator<out T> { T Current { get; } bool MoveNext(); } Notice the convenient use the pre-existing out keyword. Besides the benefit of not having to remember a new hypothetic covariant keyword, out is easier to remember because it defines that the generic type parameter can only appear in output positions — read-only properties and method return values. In a similar way, the way to define a type parameter as contravariant is using the in generic modifier: public interface IComparer<in T> { int Compare(T x, T y); } Once again, the use of the pre-existing in keyword makes it easier to remember that the generic type parameter can only be used in input positions — write-only properties and method non ref and non out parameters. Because covariance and contravariance apply only to the generic type parameters, a generic type definition can have both covariant and contravariant generic type parameters in its definition: public delegate TResult Func<in T, out TResult>(T arg); A generic type parameter that is not marked covariant (out) or contravariant (in) is invariant. All the types in the .NET Framework where variance could be applied to its generic type parameters have been modified to take advantage of this new feature. In summary, the rules for variance in C# (and .NET) are: Variance in type parameters are restricted to generic interface and generic delegate types. A generic interface or generic delegate type can have both covariant and contravariant type parameters. Variance applies only to reference types; if you specify a value type for a variant type parameter, that type parameter is invariant for the resulting constructed type. Variance does not apply to delegate combination. That is, given two delegates of types Action<Derived> and Action<Base>, you cannot combine the second delegate with the first although the result would be type safe. Variance allows the second delegate to be assigned to a variable of type Action<Derived>, but delegates can combine only if their types match exactly. If you want to learn more about variance in C# (and .NET), you can always read: Covariance and Contravariance in Generics — MSDN Library Exact rules for variance validity — Eric Lippert Events get a little overhaul in C# 4, Afterward: Effective Events — Chris Burrows Note: Because variance is a feature of .NET 4.0 and not only of C# 4.0, all this also applies to Visual Basic 10.

    Read the article

  • Covariance and Contravariance on the same type argument

    - by William Edmondson
    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 contravariant? Edit: My understanding was that arrays were actually both covariant and contravariant. public class Pet{} public class Cat : Pet{} public class Siamese : Cat{} Cat[] cats = new Cat[10]; Pet[] pets = new Pet[10]; Siamese[] siameseCats = new Siamese[10]; //Cat array is covariant pets = cats; //Cat array is also contravariant since it accepts conversions from wider types cats = siameseCats;

    Read the article

  • Safe Covariance and Contravariance in .NET 4.0

    .NET Developers may not recognize the terms invariance, covariance, and contravariance, it is likely they have been impacted by them and left wondering. This article will explain the concepts and the changes being introduced as part of .NET Framework 4.0.

    Read the article

  • C# 4.0: Covariance And Contravariance In Generics Made Easy

    - by Paulo Morgado
    In my last post, I went through what is variance in .NET 4.0 and C# 4.0 in a rather theoretical way. Now, I’m going to try to make it a bit more down to earth. Given: class Base { } class Derived : Base { } Such that: Trace.Assert(typeof(Base).IsClass && typeof(Derived).IsClass && typeof(Base).IsGreaterOrEqualTo(typeof(Derived))); Covariance interface ICovariantIn<out T> { } Trace.Assert(typeof(ICovariantIn<Base>).IsGreaterOrEqualTo(typeof(ICovariantIn<Derived>))); Contravariance interface ICovariantIn<out T> { } Trace.Assert(typeof(IContravariantIn<Derived>).IsGreaterOrEqualTo(typeof(IContravariantIn<Base>))); Invariance interface IInvariantIn<T> { } Trace.Assert(!typeof(IInvariantIn<Base>).IsGreaterOrEqualTo(typeof(IInvariantIn<Derived>)) && !typeof(IInvariantIn<Derived>).IsGreaterOrEqualTo(typeof(IInvariantIn<Base>))); Where: public static class TypeExtensions { public static bool IsGreaterOrEqualTo(this Type self, Type other) { return self.IsAssignableFrom(other); } }

    Read the article

  • What is Covariance and Contravariance

    - by xyz
    Please explain me in simple terms (if possible simple example) the covariance and contravariance in c# .net . I know many are available(even in stackoverflow) but my problem is in which scenario I should use that is not explained in the articles that I am refering to. e.g. Covariance and Contravariance in Delegates (C# Programming Guide) Thanks

    Read the article

  • Why the concept of "Covariance" and "Contravariance" are applicable while implementing the methods o

    - by Amy
    The use case is some what like this: public class SomeClass: IClonable { // 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 derivd from objec)" 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 implemementaion of Microsoft ????

    Read the article

  • Covariance and contravariance real world example

    - by Sir Psycho
    I'm having a little trouble understaing how I would use covariance and contravariance in the real world. So far, the only example's I've seen have been the same old array example. object[] objectArray = new string[] { "string 1", "string 2" }; It would be nice to see an example that would allow me to use it during my development if I could see it being used elsewhere. Can anyone point me to some useful resources?

    Read the article

  • Is there a way to determine the Variance of an Interface / Delegate in C# 4.0?

    - by BFree
    So now that we have generic Covariance and Contravariance on interfaces and delegates in C#, I was just curious if given a Type, you can figure out the covariance/contravariance of its generic arguments. I started trying to write my own implementation, which would look through all of the methods on a given type and see if the return types and or arguments match the types in the generic arguments. The problem is that even if I have this: public interface IFoo<T> { void DoSomething(T item); } using my logic, it LOOKS like it should be contravariant, but since we didn't actually specify: public interface IFoo<in T> { void DoSomething(T item); } (the in parameter) it isn't actually contravariant. Which leads to my question: Is there a way to determine the variance of generic parameters?

    Read the article

  • Instantiating a list of parameterized types, making beter use of Generics and Linq

    - by DanO
    I'm hashing a file with one or more hash algorithms. When I tried to parametrize which hash types I want, it got a lot messier than I was hoping. I think I'm missing a chance to make better use of generics or LINQ. I also don't like that I have to use a Type[] as the parameter instead of limiting it to a more specific set of type (HashAlgorithm descendants), I'd like to specify types as the parameter and let this method do the constructing, but maybe this would look better if I had the caller new-up instances of HashAlgorithm to pass in? public List<string> ComputeMultipleHashesOnFile(string filename, Type[] hashClassTypes) { var hashClassInstances = new List<HashAlgorithm>(); var cryptoStreams = new List<CryptoStream>(); FileStream fs = File.OpenRead(filename); Stream cryptoStream = fs; foreach (var hashClassType in hashClassTypes) { object obj = Activator.CreateInstance(hashClassType); var cs = new CryptoStream(cryptoStream, (HashAlgorithm)obj, CryptoStreamMode.Read); hashClassInstances.Add((HashAlgorithm)obj); cryptoStreams.Add(cs); cryptoStream = cs; } CryptoStream cs1 = cryptoStreams.Last(); byte[] scratch = new byte[1 << 16]; int bytesRead; do { bytesRead = cs1.Read(scratch, 0, scratch.Length); } while (bytesRead > 0); foreach (var stream in cryptoStreams) { stream.Close(); } foreach (var hashClassInstance in hashClassInstances) { Console.WriteLine("{0} hash = {1}", hashClassInstance.ToString(), HexStr(hashClassInstance.Hash).ToLower()); } }

    Read the article

  • In C#, are event handler arguments contravariant?

    - by Roger Lipscombe
    If I have a class that raises an event, with (e.g.) FrobbingEventArgs, am I allowed to handle it with a method that takes EventArgs? Here's some code: class Program { static void Main(string[] args) { Frobber frobber = new Frobber(); frobber.Frobbing += FrobberOnFrobbing; frobber.Frob(); } private static void FrobberOnFrobbing(object sender, EventArgs e) { // Do something interesting. Note that the parameter is 'EventArgs'. } } internal class Frobber { public event EventHandler<FrobbingEventArgs> Frobbing; public event EventHandler<FrobbedEventArgs> Frobbed; public void Frob() { OnFrobbing(); // Frob. OnFrobbed(); } private void OnFrobbing() { var handler = Frobbing; if (handler != null) handler(this, new FrobbingEventArgs()); } private void OnFrobbed() { var handler = Frobbed; if (handler != null) handler(this, new FrobbedEventArgs()); } } internal class FrobbedEventArgs : EventArgs { } internal class FrobbingEventArgs : EventArgs { } The reason I ask is that ReSharper seems to have a problem with (what looks like) the equivalent in XAML, and I'm wondering if it's a bug in ReSharper, or a mistake in my understanding of C#.

    Read the article

  • .NET 4.0 Generic Invariant, Covariant, Contravariant

    - by Sameer Shariff
    Here's the scenario i am faced with: public abstract class Record { } public abstract class TableRecord : Record { } public abstract class LookupTableRecord : TableRecord { } public sealed class UserRecord : LookupTableRecord { } public interface IDataAccessLayer<TRecord> where TRecord : Record { } public interface ITableDataAccessLayer<TTableRecord> : IDataAccessLayer<TTableRecord> where TTableRecord : TableRecord { } public interface ILookupTableDataAccessLayer<TLookupTableRecord> : ITableDataAccessLayer<TLookupTableRecord> where TLookupTableRecord : LookupTableRecord { } public abstract class DataAccessLayer<TRecord> : IDataAccessLayer<TRecord> where TRecord : Record, new() { } public abstract class TableDataAccessLayer<TTableRecord> : DataAccessLayer<TTableRecord>, ITableDataAccessLayer<TTableRecord> where TTableRecord : TableRecord, new() { } public abstract class LookupTableDataAccessLayer<TLookupTableRecord> : TableDataAccessLayer<TLookupTableRecord>, ILookupTableDataAccessLayer<TLookupTableRecord> where TLookupTableRecord : LookupTableRecord, new() { } public sealed class UserDataAccessLayer : LookupTableDataAccessLayer<UserRecord> { } Now when i try to cast UserDataAccessLayer to it's generic base type ITableDataAccessLayer<TableRecord>, the compiler complains that it cannot implicitly convert the type.

    Read the article

1 2  | Next Page >