New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavioural difference between collection.SortedMap and immutable.SortedMap #3326
Comments
Imported From: https://issues.scala-lang.org/browse/SI-3326?orig=1 |
@paulp said: Also: although I did say on the list that it is hard to say this is desirable or expected beahvior, that may not translate to it being a bug, because it is at least predictable if you know how to predict. Whether or not we do much about this one, the more general issue of controlling the impact of expected return type bears more examination. |
@oxbowlakes said: As for whether this is a bug, I guess that because of the scala implicits, it is difficult to know that a method on a sub-trait does not actually override a method on a super-trait, but instead overload it. I would say that such overloading in the standard library should be kept to an absolute minimum, or removed altogether. I lost half a day yesterday debugging this problem and I suspect that it lies in wait for many others! |
@paulp said:
You could not be more right about that. The example which springs to mind is MapLikeBase, which until I removed it relatively recently, overloaded '+' across subtypes of Map, causing a massive behavioral change if the static type of the argument changed. Unfortunately in addition to it not being easy to know as a user of the libraries whether a method overloads across subtyping, it's not easy to know as an AUTHOR of the libraries whether it does so. I mean there's nothing which says "hey man, that method has the same name as a method in the supertype and an only slightly different signature." So the great advantage of having "override" language-enforced slips away. Sounds like a warning-to-be for my ever-expanding list of things which ought to be in a linty tool. |
@dubochet said: |
@axel22 said: Other than that, the return type of |
The ++ method behaves differently on a variable types as a collection.SortedMap from an immutable.SortedMap. In the former case, the "current" ordering is ignored and the default ordering used instead.
In the code appended below, if you run it as is: you will get the following output (which I would expect):
Map(5 -> Foo, 4 -> Bar, 2 -> Hello, 1 -> World)
If, however, you change the import line as I have indicated, the following (unexpected) output occurs (i.e. the resulting map m3 has the default ordering and not that inherited from m1).
This is because the immutable.SortedMap trait overrides the ++ method whereas the collection.SortedMap does not (and hence the default CanBuildFrom comes into scope which, in turn, pulls in the default Ordering[Int])
Here is the code example:
The text was updated successfully, but these errors were encountered: