Easily overused though

# announcements

[spand]

Easily overused though

[Michael de Kaste]

I see it the other way around though. Apparently people are extremely afraid of inheritance.

[thanksforallthefish]

hopefully the new generation of developers will grow up less bound to mantras (which are not wrong per se, but are applied blindly). one of those was composition over inheritance and like all other mantras was probably largely misunderstood and lead to current designs avoid inheritance like the plague

[Michael de Kaste]

It is indeed something I have to actively fight back at my job. Even the most simplest of cases people go with composition.

[spand]

The negative I see is more that people no longer try to encapsulate the variation behind an interface and let it flow out to when expressions hundreds of places in the codebase

[Michael de Kaste]

well perhaps if you could provide an example.

An example I had where I want to use sealed classes is when I had a class with multiple fields that could only exist in specific subsituations. e.g.

lets say A1 and A2 extend A

a situation could call for either: (A1, B), (A2,C) and (A)

The situation I then see is people simply using (A,B?,C?) because it's the least restrictive of the three and encapsulate the other two. However this is a perfect situation to use sealed classes to show that there is actually only 3 cases here. And that for instance (A, B, C) cannot exist. Hiding information like that only works short term as you can have programmers actively telling each other what the cases are, but as code ages and usage drops, someone in the future might manually check stuff.

Never hide situations behind semantics. Never hide information that could be useful

[spand]

A sealed class enthusiast might make:

sealed class Number
class Int(bits: Array<Bit>) : Number
class Long(bits: Array<Bit>) : Number

This leads to usages having when (number) { is Int -> ..., is Long -> ... }.
Now when I want to add a Double to that sealed class I break every single usage.

Instead one could thought a bit harder about it and have made a Number interface and exposed relevant methods that is then implemented in the concrete classes as is proper OO.

[Michael de Kaste]

if that's the usecase you see them used for then I can agree with you. I've personally never seen it.

[Nir]

I'd really prefer to have sum types

[Michael de Kaste]

I guess you mean Union Types? And I heavily agree

[asad.awadia]

^thats how I have been using sealed classes as

[Nir]

the problem with using them that way is that they're intrusive

[Nir]

because inheritance is intrusive

[Nir]

which sucks, a lot

[Nir]

e.g. if you want to model Json as null | String | Integer | Double | List<Json> | Map<string, Json>

[Nir]

you can't do it. because you can't put things like String in a sealed class.

[Nir]

so you need something to hold the String, Integer, etc. But then that thing cannot be generic because type erasure, so you have to write out a bunch of separate wrapper types.

[Nir]

And then it causes further headaches afterwards when you try to write functions

[Nir]

possible the compile time interfaces proposal would effectively alleviate this issue (although it would still be pretty verbose, but at least it would be possible)