3 ms·
Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's
by Groxx 5y ago
Yeah - personally I think languages should allow a lot of constraints like sealed classes (it makes your intent clear, and can allow extra optimizations, that's good!), but highly-risky "escape hatches" need to exist because they solve real problems.
"Fork and modify" is a very capable alternative, but it's far, far, far more costly than "monkey-patch this one time issue that'll be fixed next week". And some languages make it extremely painful to achieve, often requiring significant code rewriting, and which sometimes make contributing back to the source-library significantly harder. And when such hacks hang around longer for a week... well, sometimes that's fine, sometimes it's not, and the library author is not the one who should be making that decision. It's my program, it should do what I tell it to do.
- Ericson2314 5y agoA sealed class ought to have no methods, so it is plain old data. Then there's no purpose to overriding it.
- Groxx 5y agoI think you're thinking of `record` classes? Sealed classes are about constraining inheriting or implementing to only approved types - using sealed is pointless without overriding of some kind. Unlike in some other languages, where sealed is closer to java's final classes, i.e. stopping inheritance.
- Ericson2314 5y agoIf they are like Scala's I do mean sealed.
- Groxx 5y agoThe only thing I can find on Scala with "sealed" is for exhaustive pattern-matching on types, which 1) broadly matches Java, and 2) has nothing to do with data-only objects at all. Sealing and methods are entirely orthogonal.
- lolinder 5y agoIn Kotlin, I use sealed classes as a substitute for union types, and that means for the most part they have no functions.