2 ms·
But you don't have an alternative. You subclassed things and someone broke the base class. It happens. But there is no other magic bullet (whether it be all
by wvenable 8y ago
But you don't have an alternative. You subclassed things and someone broke the base class. It happens. But there is no other magic bullet (whether it be all functional programming or something else) that solves that problem. Most just make extension impossible, which isn't really better.
> The "sealed" classes are meant to be semantic boundaries.
The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right?
- pdimitar 8y ago> The author of the "sealed" class definitely imagined all possible use cases and their code has absolutely no bugs, right? ...What? You can compose an instance of the sealed class in yours. You lose all brittleness from inheritance in the process. I've been coding OOP most of my life and I am working with FP for 2 years now -- composition never introduced a bug. Sure it's anecdotal but after a trend repeats itself 5+ times, you start observing patterns and making conclusions. Additionally, a number of FP languages offer Java-like and Go-like interfaces for an extra peace of mind.
- wvenable 8y ago> You can compose an instance of the sealed class in yours. But I can't subclass a sealed class to fix a bug or add a feature and pass it back into the framework to use. And yes, I have needed to do this otherwise I would never notice it was sealed in the first place.