-
Notifications
You must be signed in to change notification settings - Fork 21
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
Forbid final object
#11094
Comments
Fix scala#4936. - Stop using final object in our sources. - Give error for abstract and sealed objects, warning for final ones (as long as - scala/bug#11094 is open).
Fix scala#4936. - Stop using final object in our sources. - Give error for abstract and sealed objects, warning for final ones (as long as - scala/bug#11094 is open).
Fix scala#4936 in parser. - Stop using final object in our sources. - Give error for abstract and sealed objects, warning for final ones (as long as - scala/bug#11094 is open). - Address review comments.
Fix scala#4936 in parser. - Stop using final object in our sources. - Give error for abstract and sealed objects, warning for final ones (as long as - scala/bug#11094 is open). - Address review comments.
Wasn't aware. Is that so??? |
Sure. Take the following code: class Test {
case object foo
} Compiled with 2.12.7, this yields the following decompiled bytecode: public class Test$foo$ implements scala.Product,scala.Serializable {
// [...] On the other hand, the same code using 2.11.8, or the following code in 2.12.7: class Test {
final case object foo
} Both compile to: public final class Test$foo$ implements scala.Product,scala.Serializable {
// [...] |
Thanks! FWIW this is even advice: https://nrinaudo.github.io/scala-best-practices/adts/final_case_objects.html. So, the last Dotty release gets this right. (Somebody should add a test to ensure that stays the case). I won't speculate on how hard changing this will be in Scalac 2.14, if 2.13 doesn't fix it already. |
Scalac sometimes *forgets* the final bytecode flag, and sometimes one cares, so people even *recommend* always writing *final object* instead of object. That's bad, since we started warning about it in scala#4973. scala/bug#11094 (comment) https://nrinaudo.github.io/scala-best-practices/adts/final_case_objects.html Why care? ========= If we forget the final flag in bytecode, Java code might then extend the class. Performance might or might not be affected - some in scala/contributors debated this for ~20 minutes (starting at https://gitter.im/scala/contributors?at=5c423c449bfa375aab21f2af).
Because of (edit: oh, mentioned in Seth's SO) |
Happy it’s gone in 2.13. Since Dotty can’t shadow classes, it can’t do that either. |
Scalac sometimes *forgets* the final bytecode flag, and sometimes one cares, so people even *recommend* always writing *final object* instead of object. That's bad, since we started warning about it in scala#4973. scala/bug#11094 (comment) https://nrinaudo.github.io/scala-best-practices/adts/final_case_objects.html Why care? ========= If we forget the final flag in bytecode, Java code might then extend the class. Performance might or might not be affected - some in scala/contributors debated this for ~20 minutes (starting at https://gitter.im/scala/contributors?at=5c423c449bfa375aab21f2af).
Scalac sometimes *forgets* the final bytecode flag, and sometimes one cares, so people even *recommend* always writing *final object* instead of object. That's bad, since we started warning about it in scala#4973. scala/bug#11094 (comment) https://nrinaudo.github.io/scala-best-practices/adts/final_case_objects.html Why care? ========= If we forget the final flag in bytecode, Java code might then extend the class. Performance might or might not be affected - some in scala/contributors debated this for ~20 minutes (starting at https://gitter.im/scala/contributors?at=5c423c449bfa375aab21f2af).
First reported in scala/scala3#4936; both
sealed
andfinal
are redundant onobject
, butfinal object
seems pretty common (though it's redundant).OTOH,
final object
seems pretty common, and it even appears in the new collections, maybe because it is sometimes used in such pattern (from Dotty) — andfinal
on case classes does make sense.We're considering changing this in Dotty in scala/scala3#4973, but it'd be good to do the change in 2.14 as well I guess — or (EDIT) at least agree that we want to do it.
The text was updated successfully, but these errors were encountered: