i m SOL right

Question

i m SOL right

streetsofboston · Answer

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

ursus · Answer

But then base layer knows about subclass layer

ursus · Answer

I add QuaxAction to the base sealed hierarchy right

streetsofboston · Answer

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

Mike · Answer

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 · Answer

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

Mike · Answer

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 · Answer

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 · Answer

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 · Answer

Should I make that not sealed I will use when exhaustiveness

streetsofboston · Answer

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 · Answer

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

streetsofboston · Answer

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 · Answer

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

streetsofboston · Answer

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 gt handleAction baseAction is NoAction gt 0 fun handleAction updateAction UpdateAction Int return when updateAction is InsertAction gt 1 is DeleteAction gt 2 ```

ursus · Answer

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

ursus · Answer

Its like putting subclass code in base class

ursus · Answer

Why should base class know about subclass stuff at all

streetsofboston · Answer

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 · Answer

Yea oh well thanks

streetsofboston · Answer

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 · Answer

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

streetsofboston · Answer

True slightly smiling face 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 · Answer

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