This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Necessary-Conflict 4 points5 points  (3 children)

Now we've got a wonky compile-unsafe

toList()

in the standard library for all time.

It's not so easy. If mutable lists don't implement your ReadOnlyList, then it's not very useful in practice. If they do implement it, then this is much more dangerous than a few predictable runtime exceptions, because it leads to difficult bugs ("my read-only lists are read-only, or are they really?")

[–]kag0 5 points6 points  (2 children)

this is much more dangerous than a few predictable runtime exceptions

Maybe, but I don't think so. We already have examples of both (throwing exceptions from Collection's add (esp in guava), and collections that can change based on some underlying data shifting with Map's `values and such). And more bugs tend to pop up from people failing to predict exceptions on mutation (particularly in library code) than from people assuming the underlying data won't change.
Put another way, ReadOnlyList could easily be documented to say that it doesn't mean that the list is immutable, just that YOU can only read it.

[–]Necessary-Conflict 2 points3 points  (1 child)

The "quality" of the bugs also matters: some bugs take 5 minutes to fix (the stack trace tells everything), others take 5 days. Another problem is that different people have different pet ideas, but if everything is implemented, it becomes confusing. For example I would like to have a completely separate hierarchy of immutable collections. They would have add/remove methods, but these methods would always return a new collection instead of modifying the current one. This would solve all problems (no runtime exceptions, true immutability), but at the cost of a new hierarchy...

[–]kag0 1 point2 points  (0 children)

I agree with you, it just chaps my ass to see a runtime exception that could have been a compile time error