My preference would be for the language flag to give the warning or error, but no warning or error with no language flag. So there would only be disruption for those that wanted it.
The whole point is to prevent something that could happen just in case either the developer forgets to mark the class as final/sealed or the user extends something that is not meant to be extended by mistake. This can only be done by requiring the flag. IMO, a language flag is no disruption.
5 Likes
Let’s not forget that you can add -language:adhocExtensions to compiler options and thus silence all warnings about extending non-open non-final classes. Adding -language:xxx to compiler options is equivalent to adding import scala.language.xxx to all .scala files in your project.
3 Likes
@soronpo Once again, this is an inclusion of a core feature to the language which dictates a controversial opinion (among the “contributors”, mind you). This is not just the flag, it’s also the documentation that has changed in the PR, which now contains a part about the motivation behind the flag and instructions on best-practices, which are being argued against in this very discussion and the previous (quite long) discussion.
2 Likes
Hi Martin & the Scala community,
I have to confess that I’m not that close the details of the Scala language design, but I do have a fear of whether Scala 3 is exhibiting second system syndrome. I think that Dotty/Scala 3 has some excellent new features that will help developers. But it also seems like some very significant language changes are being made right before the Scala 3 cutoff deadline. In my experience, rushing stuff in just before the deadline is usually a mistake …
In particular, the changes to implicit syntax, significant whitespace, and class scope changes, may end up not being the right choice in the long term.
I think that if Scala 3 ends up being too different from Scala 2 then you will end up with exactly the same issue as Python 2/3, which is still being worked out today.
If a particular feature is controversial then I would suggest that it is may be safer to leave it out of Scala 3, continue working on it until it is shown to be definitely better before adding it to a Scala 4. I don’t think that there is any reason why Scala 4 couldn’t be released in 2-3 years time, if that was the right thing to do.
Kind regards,
Rob
7 Likes
Most java’s best practices suggest to use final classes (Effective java, official concurrency tutorial). FP also favors this approach.
OTOH, many popular java libs/frameworks like JPA, Jackson, Spring require nonfinal, mutable POJOs. In Kotlin land they have the “allopen” plugin to open certain classes by default…
But there are not many Scala users that use those libs.
So, all in all, it is natural/preferrable to have classes final as a default. But, it’s a dangerous decision to make IMHO. I couldn’t imagine e.g. Java to switch to final classes by default… Maybe for case classes only, but regular ones…
4 Likes
I would say that even “barely tested” is an extreme case. Even well tested/designed libraries often need to be extended in ways the author didn’t imagine and these kind of things are only realized usually after a few major versions.
People don’t often create “perfect” libraries right from the start and they also don’t envisage every kind of way it could be legitimately extended.
2 Likes