> I find this sentiment- expressed now twice in this discussion- more > than a little bit surprising. I mean, even in Ocaml, whose user base > includes a huge percentage of type theorists, the general method for > handling co-/contra-variance issues is to just avoid them like the > plague. Even the people who understand the subtleties of the issue > (and I don't count amount that number) tend to avoid it. The > introduction of co-/contra-variance issues into Java with generics > caused a huge amount of sturm und drang in the Java community- the > resolution of which, as near as I can tell, was for the vast bulk of > Java developers to simply ignore the issues, and revert to subverting > the type system and using run-time checking instead (i.e. explicit > casting).
Having given it more thought, I'm willing to admit that yes, variance may be necessary (or very near to it). This is more than a little annoying though. Covariance is not a problem in and of itself, and follows nicely by the standard subtype checker. Contravariance screws everything up. Use site variance is essential if you want declaration site variance to have any positive impact on your language, and now you're getting back into dangerous waters. I would be very tempted to just avoid the variance issue altogether. Some things may not be worth sacrificing for. The question is whether or not this will lead to a *lot* of downcasting in common use, or if it can be avoided in practice. Daniel -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
