-- David
On Sat, May 28, 2011 at 3:33 PM, Meredith Gregory
Meredith> Dear Scalarazzi, i was surprised by the following.
http://stackoverflow.com/questions/676615/why-is-scalas-immutable-set-not-covariant-in-its-type
I don't think the question was ever fully answered. Daniel makes it
clear the issue is the contains method. For both List and Set, you can
either have covariance, or you can have a contains method that takes an
A (instead of Any), but you can't have both.
In the case of List, covariance was chosen, and List.contains takes Any.
In the case of Set, invariance was chosen, and Set.contains takes A.
The question remains: why was this design decision made?
--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
Is there any chance of such a change being considered?
Kris
mmm, makes me think of typeclasses.
Dear Martin,Thanks for your input! If i understand correctly, it will be up to the community to grow some separate Set-like collections with consistent variance; and, if needed, provide views of these collections as functions. That sounds like a worthy task!Also, just for my own understanding, can you provide pointers to information about the approach to binary compatibility?
We have developed a tool that will help you diagnose binary incompatibilities. We plan to get it out as a beta during Scala Days
(so just a few days from now!).
As for more detailed information on the sort of binary incompatibilities that the tool checks, I'm working on a document that I hope
will be soon public. It should help taking the right decisions when evolving your classes and traits. The form is similar to
Java's binary compatibility document (http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html).
Of course if you have specific questions I'll be happy to answer them.
Cheers,
Mirco