Co- and contra-variance: how do I convert a List(Of Apple) into a List(Of Fruit)?

Only need have one key work

ljw1004 — Fri, 03 Oct 2008 00:45:53 GMT

[posted by btcheng]

It seems to me you only need to have one key work Like x as CLONE List(Of T) on function call. Then in the scope of the method x will reference clone of List(Of T). Everything works as normal. Modifications of list are bound into scope of the method or object and will not have effect callers list. Furthermore modifications to objects in the list will persist out of scope which is porsumably is a desired result. This would allow stuff like is.

Class Fruits

Public Property Washed() As Boolean

Public Property Eaten() As Boolean

End Class

Class WashedFruitList

Private mList As List(Of Fruits)

Public Sub New(ByVal NewList As List(Of Fruits))

For Each Fruit As Fruits In NewList

Fruit.Washed = True

mList = NewList

End Sub

Public Sub EatList()

For Each Fruit As Fruits In mList

Fruit.Eaten = True

mList=New List(Of Fruits)

End Sub

Public Sub Add(ByVal itm As Fruits)

itm.Washed = True

mList.Add(itm)

End Sub

End Class

Dim lApples As New List (Of Apples)

Dim CartFriut as WashedFruitList

CartFriut = New WashedFruitList(lApples)

' All apples in lApples would be washed

CartFriut.Add(BobsBanana)

' lApples would only still have Apples

lApples.Add(NewApple1)

lApples.Add(NewApple2)

CartFriut.EatList

' LApples Still Exist Members and all members of LApples would be eaten except NewApple1, and NewApple2

If you want further clarification email me @ btcheng@yahoo.com

call-site variance

ljw1004 — Fri, 03 Oct 2008 00:46:30 GMT

[posted by Anonymous]

It seems to me that declaration-site variance (as implemented in the CLR, and now proposed for C# and VB.NET) is less useful than call-site variance (as implemented in Java using wildcards). Here's why: stop for a moment and think, how many of BCL generic classes could actually be converted to use this feature? There's IEnumerable<T>, alright - but what else? ICollection<T> is right out, because it is IEnumerable<T> (and hence covariant), but it also takes T as an argument for Add() (which is contravariant) - the intersection of those is invariant. The same goes for all interfaces further extending ICollection<T>, such as IList<T>.

On the other hand, with wildcards, I can deal with ICollection<T> either in covariant or contravariant fashion: for example, only using GetEnumerator() and Count - a typical real-world scenario - is covariant; only using Add() is contravariant. You can do this with declaration-site variance too, but you have to split every interface into its covariant and contravariant parts, and I doubt the BCL team would do it at this point; besides, it relies upon interface designers to do the right thing, and gives the user no recourse if they don't.

call-site variance

ljw1004 — Fri, 03 Oct 2008 00:55:02 GMT

Agreed, declaration-site variance does rely on interface designers to do the right thing, and yes I too doubt the BCL team would do it at this point.

re: Co- and contra-variance: how do I convert a List(Of Apple) into a List(Of Fruit)?

Branco Medeiros — Thu, 16 Oct 2008 06:59:36 GMT

This is good stuff!

(Btw, welcome aboard! It's a pitty Paul Vicky is moving out, but I guess a fresh new pair of eyes over the language will be a good thing!)

There were many times I felt the need of covariance (the Out thing), and I knew there was support for it in the CLI. Good to know it's on your radar. And the syntax seems to fit nicely (too bad parameter constness can't be enforced in the CLI, that would probably easy things out for covariance, I guess).

Now there are a few other things the CLI provides that VB could actually have: managed pointers, method Jumping and (ta-dah!) custom array lower bounds =)))

Congratulations for the very interesting post.

Branco.