Talk:Covariance and contravariance (computer science): Difference between revisions

Content deleted Content added

Inline

Revision as of 08:16, 7 June 2008

This really needs to be cleaned up with some explanation that is not so heavily tied to object-oriented programming. --Saforrest 06:17, 18 April 2006 (UTC)[reply]

Go on then, be bold! Most of my knowledge of co/co is limited to an OO context, so I'm not in a position to write it sadly. It might be worth noting that it's Covariance and contravariance (computer science) not Covariance and contravariance. StephenFalken 06:29, 18 April 2006 (UTC)[reply]

Yes, it applies to OO but the terms come from category theory as applied to types in programming languages. I'm far from being an expert in the topic, but after reading here and there and not finding a concrete answer I decided to edit the page with what I found. Hope it helps. / Carlos Aya 03:58, 5 September 2006 (UTC)[reply]

Ah, please check the spelling / writing style as english is not my mother tongue. / Carlos Aya 04:05, 5 September 2006 (UTC)[reply]

Well, I think we have something clean, explaining the terms in general and applied to OO. The languages part section at the end needs review. Carlos Aya 05:43, 20 September 2006 (UTC)[reply]

I agree -- I think is is very important that the OO language application details remain. There should be some discussion on the relationship with generics. Adw2000 14:30, 14 June 2007 (UTC)[reply]

Contravariance and Generic Programming

This should mention the fact that generic programming supports covariant arguments. For example, adding an element to an STL BackInsertionSequence of type X means adding an X::value_type whereas std::vector<int> (which is a BackInsertionSequence) means adding an int. While int is std::vector<int>::value_type, it is not a subtype of X::value_type. —Ben FrantzDale 18:27, 15 June 2007 (UTC)[reply]

Sentence needs editing

The following sentence is very cumbersome. Could someone who understands the issues improve it?

"How types are built from basic types, thus defining the sub-type relationship, and how new methods are defined and override or not existing methods depends on the language and sometimes not necessarily follow the substitution principle above adding runtime checking instead."

Dougher (talk) 03:00, 28 November 2007 (UTC)[reply]

Bad example

The first example is unclear if not broken:

"The array type is usually covariant on the base type: since String ≤ Object then ArrayOf(String) ≤ ArrayOf(Object)."

The definition talks about type operators being either covariant, contravariant or invariant. Now suddenly the array type is supposed to be covariant?

"if insert and remove operators are permitted, then the insert operator is covariant (e.g. one can insert a String into an ArrayOf(Object)) and the remove operator is contravariant"

Insert and remove are not type operators. So again, how does this relate to the definition?

I think the example should mention that type safety requires

ArrayOf to be covariant for read only arrays,
ArrayOf to be contravariant for write only arrays,
and ArrayOf to be invariante otherwise.

--83.77.239.59 (talk) 16:24, 25 December 2007 (UTC)[reply]

Ordering

The first sentence says

A covariant type operator in a type system preserves the ordering ≤ of types.

Fine, but what is this ordering? This article does not explain it, and neither does type system

The very model of a minor general (talk) 21:53, 1 April 2008 (UTC)[reply]

What is covariant?

The first sentence says that a type operator may be covariant or contravariant. The rest of the article speaks about covariant or contravariant types. What does it mean for a type to be covariant?

Also: I am sure we have an article explaining what a "type operator" is; please link to it.

--The very model of a minor general (talk) 19:50, 4 April 2008 (UTC)[reply]

I agree. I made a stab at cleaning it up. —Ben FrantzDale (talk) 03:20, 6 April 2008 (UTC)[reply]

Covariance/Contravariance are not properties of a type or a method (function, procedure) alone. Rather, they are relations between a method and its argument and result types. Whenever a contravariant type is mentioned, it must be clear from the context what method it is being related to and what position (argument v. result) in the method it is taking. —Preceding unsigned comment added by 118.68.180.142 (talk) 21:07, 6 June 2008 (UTC)[reply]

Fact on Castagna's work

The sentence

"it was shown by Castagna (1995) that all depends on the method fetching algorithm: types used to select the method are contravariant; types not used to select the method are covariant. It is immaterial if the fetching occurs at run-time or at compile time."

is completely wrong. Castagna (1995) has proved exactly the opposite: "given a method m selected by a messages with parameters, when m is overridden, the parameters that determine the (dynamic) [method] selection must be covariantly overridden (i.e., the corresponding parameters in the overriding method must have a lesser type). Those parameters that are not taken into account in the selection must be contravariantly overridden (i.e., the corresponding in the overriding method must have a greater type.)"