https://kotlinlang.org logo
#announcements
Title
# announcements
u

ursus

07/15/2019, 12:58 AM
i'm SOL, right?
s

streetsofboston

07/15/2019, 1:01 AM
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.
u

ursus

07/15/2019, 1:24 AM
But then base layer knows about subclass layer
I add QuaxAction to the base sealed hierarchy, right?
s

streetsofboston

07/15/2019, 1:49 AM
I think I misunderstood you, then. Could you show the hierarchy you had in mind?
m

Mike

07/15/2019, 11:59 AM
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.
u

ursus

07/15/2019, 2:56 PM
@Mike like how? if the sealed hierarchy is in a different package / library? you cannot extend that afaik in any way
m

Mike

07/15/2019, 3:01 PM
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.
s

streetsofboston

07/15/2019, 3:04 PM
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.
💯 1
u

ursus

07/15/2019, 3:46 PM
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
Should I make that not sealed? I will use when exhaustiveness
s

streetsofboston

07/15/2019, 3:49 PM
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.
u

ursus

07/15/2019, 3:54 PM
Yes im in the author, but that is poor design imho. Why should BaseState know about Insert Delete etc ? That cannot scale
s

streetsofboston

07/15/2019, 3:57 PM
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.
Or you can make BaseState sealed as well…. it’s up to you.
E.g :
Copy code
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
    }
}
u

ursus

07/15/2019, 4:11 PM
I know this is possible, but isnt that bad design? Insert and Delete action will only live at subclass layer
Its like putting subclass code in base class
Why should base class know about subclass stuff at all
s

streetsofboston

07/15/2019, 4:21 PM
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.
u

ursus

07/15/2019, 4:26 PM
Yea, oh well, thanks
s

streetsofboston

07/15/2019, 5:15 PM
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?
u

ursus

07/15/2019, 7:36 PM
Yea i know, it just feels weird `when`ing over nonclosed hierarchy
s

streetsofboston

07/15/2019, 7:42 PM
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.
u

ursus

07/16/2019, 2:48 AM
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
3 Views