4 ms·

I bet we disagree on what unsafe means. Many here think tåhat shipping a non-final/open/inheritable class is unsafe. I think doing so stunts your code base’s an

I bet we disagree on what unsafe means. Many here think tåhat shipping a non-final/open/inheritable class is unsafe. I think doing so stunts your code base’s and ecosystem’s evolution. And when push comes to shove and you have to address an issue in a 3rd party library, and you are unable to override a single thing that would fix your problem because everything is closed by default, then you will tell your manager it can’t be done, and serious money or opportunity will be wasted and customers will suffer for longer, because you are coding in a really safe language. Is this progress for humanity? I think not!

mike_hearn 2y ago
That's a slightly different issue. I don't think people consider visibility attributes under the rubric of safety, usually, except in sandboxed contexts. That's more a problem of build tooling. It should be possible to modify visibility/finality levels in libraries as you download them. Gradle can do something like this with some work, but someone should make a plugin to automate it. That way the upstream can set things private/final/sealed as correct for their API guarantees and design, and downstream can apply hacks to open things up if that's easier than forking the source code, and there's a single place in the build system that collects all the places where there's a mismatch.
- yearolinuxdsktp 2y ago
  Jeez what an ugly option.
kazinator 2y ago
I've made it explicit what I believe safe means. I could discuss it in more detail, but I won't be changing my definition. I would never do such a barbaric thing as adding a non-inheritable class to an object system. Or, if I were convinced to, it would be purely for performance, not as a way of restricting the programmer; i.e. for speeding up things due to the compiler knowing that the class is final.
tasuki 2y ago
Composition over inheritance! (If you absolutely must do OOP)

mike_hearn 2y ago

That's a slightly different issue. I don't think people consider visibility attributes under the rubric of safety, usually, except in sandboxed contexts. That's more a problem of build tooling. It should be possible to modify visibility/finality levels in libraries as you download them. Gradle can do something like this with some work, but someone should make a plugin to automate it. That way the upstream can set things private/final/sealed as correct for their API guarantees and design, and downstream can apply hacks to open things up if that's easier than forking the source code, and there's a single place in the build system that collects all the places where there's a mismatch.

yearolinuxdsktp 2y ago
Jeez what an ugly option.

kazinator 2y ago

I've made it explicit what I believe safe means. I could discuss it in more detail, but I won't be changing my definition. I would never do such a barbaric thing as adding a non-inheritable class to an object system. Or, if I were convinced to, it would be purely for performance, not as a way of restricting the programmer; i.e. for speeding up things due to the compiler knowing that the class is final.

tasuki 2y ago

Composition over inheritance! (If you absolutely must do OOP)