Timeline for Why is using 'final' on a class really so bad?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2023 at 16:44 | comment | added | Anther | @Jeremy I am so glad you came back to update your comment. I was just reading your first paragraph and thought, "Well why ever declare a variable as private, or use type hints, or name variables reasonably" | |
| Dec 8, 2022 at 21:42 | comment | added | Jeremy | I just got drawn back here by a recent upvote. I no longer think this answer or the comments defending it have any merit. I hope I've learned a lot about software design since saying this. | |
| Dec 8, 2022 at 21:40 | history | edited | Jeremy | CC BY-SA 4.0 |
added 279 characters in body
|
| Jun 23, 2014 at 13:20 | comment | added | David K |
If you find in the future that you want to extend your final class after all, you can look at the class design, decide whether it is safe to extend, fix it if it isn't, then remove the final keyword. In effect, you refactor the class from final to non-final. Then you can extend it. Seems reasonable to me.
|
|
| Jul 14, 2011 at 14:38 | comment | added | Konrad Rudolph |
@Jeremy I’m not conflating keywords. The keyword final means, “this class is not to be extended [for now].” Nothing more, nothing less. Whether PHP was designed with this philosophy in mind is irrelevant: it has the final keyword, after all. Secondly, arguing from PHP’s design is bound to fail, given how patchworky and just overall badly PHP is designed.
|
|
| Jul 14, 2011 at 14:35 | comment | added | Jeremy | @Konrad Rudolph That sounds like a great opinion to bring to a question about OOP language design. But we know how PHP works, and it takes the other approach of allowing extension unless sealed. Pretending that its ok to conflate keywords because "thats how it should be" is just defensiveness. | |
| Jul 14, 2011 at 14:08 | comment | added | Konrad Rudolph |
@Jeremy But classes are by default fundamentally not apt to extension, unless specifically designed for it. So the difference is the same, and final is still an apt description.
|
|
| Jul 14, 2011 at 13:39 | comment | added | Jeremy | @Konrad Rudolph It is not miniscule at all. If other people later want to extend his classes, there is a big difference between a comment that says "not extended" and a keyword that says "may not extend". | |
| Jul 14, 2011 at 13:37 | comment | added | Konrad Rudolph |
@Jeremy The difference is minuscule. The purpose is generally to show that a class isn’t inherited from. This is final. Nothing to worry about.
|
|
| Jul 14, 2011 at 13:32 | comment | added | Jeremy | @Konrad Rudolph Please re-read the original question. He is not using final for the purpose of sealing the class. He is using it as a comment. | |
| Jul 14, 2011 at 7:10 | comment | added | SF. |
@Konrad: Except final should denote "No subclass of this class should ever be created" (for legal reasons or something), not "this class currently has no children, so I'm still safe to mess with its protected members". The intent of final is the very antithesis of "freely editable", and a final class shouldn't even have any protected members!
|
|
| Jul 14, 2011 at 6:51 | comment | added | Konrad Rudolph |
This is completely false! “ using language keywords just to signal something to you […] is a bad idea.” – On the contrary, that is exactly what language keywords are there for. Your tentative caveat, “and only you would ever know what it means”, is of course correct but doesn’t apply here; the OP is using final as expected. There’s nothing wrong with that. And using a language feature to enforce a constraint is always superior to using a comment.
|
|
| Jul 2, 2011 at 13:06 | history | answered | Jeremy | CC BY-SA 3.0 |