I suppose it isn't surprising that Odersky glosses over the fact that the new collections library in Scala isn't type-safe. They apparently just couldn't get the variances on type parameters to work out, so they cheated and added an annotation to ignore them: @uncheckedVariance.
"Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way."
Really? But not expressive enough to write the standard collections library I guess?
[UPDATE]: It gets even more amusing -- I just learned they have a paper on the collections library called "Fighting Bit Rot with Types" where they again make no mention of @uncheckedVariance. I guess mentioning that they had to cheat the type system would have undermined their goal of "focussing on the role that type systems play in keeping software architectures coherent over time."
I'm not an expert on the issue, but I believe the Stackoverflow post at http://stackoverflow.com/questions/2454281/when-is-unchecked... explains why @uncheckedVariance is currently used without all the condescension from the above post, for anyone who is curious.
Otherwise, I found the article very valuable. First, it shows you how to extend the library with your own collections. Second, I learned more about how to use Scala's language features to build an advanced library or abstraction by reading about their architecture. The library provides a good example of how to use interface and implementation traits, how to organize a complex class hierarchy (and when the type system might still get in the way of that hierarchy), and how to use implicit arguments to avoid code duplication, among other things.
Not that I disagree that it's a bad example in general if you cannot express the internals in your language using the same language... but I see why they'd do that really. "But not expressive enough to write the standard collections library I guess?" - standard, truly extensive and universal collections library is far from a "common programming patterns" really. If sticking to the type-safety which can be provided right now means weaker or less flexible collections - maybe it's the right tradeoff they made?
For more explanation on why it's needed, here's a good link: http://stackoverflow.com/questions/2454281 ("Since we can't abstract over the variance annotation (yet ;-)) in GenericTraversableTemplate, so that we could have instantiated it to either one depending on the subclass, we have to resort to casting (@uncheckVariance is essentially a kind-cast). ")
Is it really sweeping under the rug? Not only the author of the bitrot paper himself answered the question on stackoverflow by pointing out the problems, he also gave the impression that they're working on eliminating the limitation: "can't abstract over the variance annotation (yet ;-))"
"Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way."
Really? But not expressive enough to write the standard collections library I guess?
[UPDATE]: It gets even more amusing -- I just learned they have a paper on the collections library called "Fighting Bit Rot with Types" where they again make no mention of @uncheckedVariance. I guess mentioning that they had to cheat the type system would have undermined their goal of "focussing on the role that type systems play in keeping software architectures coherent over time."