i'm SOL, right?

# announcements

[ursus]

i'm SOL, right?

[streetsofboston]

If that means shit out of luck: Why are you? 😀
Just add that subclass to your sealed hierarchy and fix the code that may break because of this change.

[ursus]

But then base layer knows about subclass layer

[ursus]

I add QuaxAction to the base sealed hierarchy, right?

[streetsofboston]

I think I misunderstood you, then. Could you show the hierarchy you had in mind?

[Mike]

Sealed classes are more about controlling the inheritance hierarchy, and saying 'this is all there can be'.

Doesn't really change anything else about usual OO inheritance rules, so you should be able to solve the problem in the usual manner.

[ursus]

@Mike like how? if the sealed hierarchy is in a different package / library? you cannot extend that afaik in any way

[Mike]

Exactly. But your question seems to be more about parent/child relationship and inheritance. As long as everything you're building is in the same file, then sealed class isn't really a factor in your question. You should be able to do whatever you'd normally make.

[streetsofboston]

And having no access to modify the sealed class hierarchy in a 3rd party library is a good thing. The writers of that 3rd party lib didn’t anticipate your adding a new sub-class in the hierarchy and they protected themselves by using a sealed class hierarchy.

[ursus]

Okay ill make this concrete. I have UI, in there is a state machine, it takes sealed class Actions, and produces sealed class State. In base class I only support EditAction and EditingState or IdleState. However in leaf subclass UI I want to support more actions, yet reuse that code from base. Best would be to have the new leaft actions in the same hierarchy as base EditAction, etv @streetsofboston @Mike

[ursus]

Should I make that not sealed? I will use when exhaustiveness

[streetsofboston]

If you are the author of the sealed class hierarchy and have access to the code that uses the ‘when exhaustiveness’, then just add the new sub Actions (and sub States) and fix the code where the compiler generates errors.

If you are not the author of that code, then there’s not much you can do.

Also, if you are the author, you can have another sealed class sub-hierarchy under an already existing one and handle only that sub-hierarchy in your code if that code expects that sub-hierarchy.

[ursus]

Yes im in the author, but that is poor design imho. Why should BaseState know about Insert Delete etc ? That cannot scale

[streetsofboston]

You can make your BaseState an interface or an abstract (non-sealed) class, and have categories of state as sealed sub-class hierarchies of BaseState.

[streetsofboston]

Or you can make BaseState sealed as well…. it’s up to you.

[streetsofboston]

E.g :

sealed class BaseAction

sealed class UpdateAction : BaseAction()

class InsertAction: UpdateAction()

class DeleteAction: UpdateAction()

class NoAction: BaseAction()

fun handleAction(baseAction: BaseAction): Int {
    return when(baseAction) {
        is UpdateAction -> handleAction(baseAction)
        is NoAction -> 0
    }
}

fun handleAction(updateAction: UpdateAction): Int {
    return when (updateAction) {
        is InsertAction -> 1
        is DeleteAction -> 2
    }
}

[ursus]

I know this is possible, but isnt that bad design? Insert and Delete action will only live at subclass layer

[ursus]

Its like putting subclass code in base class

[ursus]

Why should base class know about subclass stuff at all

[streetsofboston]

Ah, you mean it's all in the same file: base and all subclasses.

Then you would need to make BaseAction an interface or a non sealed abstract class.

[ursus]

Yea, oh well, thanks

[streetsofboston]

It’s hard to have it both. Either the compiler knows about all types in a sealed hierarchy or it doesn’t….

If you were able to define sub-types of such a hierarchy outside the main hierarchy, you wouldn’t be able to use an exhaustive when-clause… How would the compiler know how to check for exhaustiveness, if some other party, that uses your code/library, suddenly ads a brand new sub-type?

[ursus]

Yea i know, it just feels weird `when`ing over nonclosed hierarchy

[streetsofboston]

True! 🙂

Sometimes a trade-off of putting the entire closed/sealed hierarchy inside one kotlin file is the right thing to do.

Most of the times, the actual values/classes of the sealed hierarchy are simple, some objects, some data-classes mostly and often they have simple member variables (string, int, boolean, enum), if any at all, and they have no real behavior (functions). The behavior is done through the exhaustive when clauses somewhere else by other classes.

[ursus]

Well, proper solution to my statemachine problem would be to compose it, that however means creating new sealed actions hierarchy for the subclass and then mapping the common EditAction case to the Base.Edit but . meh