Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:
- data types a la carte, which takes an FP style approach; and
- tagless final or object algebras, which takes an OO style approach.
Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.
Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.
In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.
Searching for "expression problem" should find other discussion of the problem and solutions. The two best known solutions to the expression problem are:
- data types a la carte, which takes an FP style approach; and - tagless final or object algebras, which takes an OO style approach.
Other solutions are possible depending on language features. E.g. the linked paper above uses mixins and units.
Overall I find the discussion in the original post to be a bit naive. It doesn't make the case that an OO approach is necessary or desirable. E.g. that an OO approach provides a form of extensibility that is needed.
In the FP world, if I wanted to build a UI toolkit I would start by defining by a combinator library (usually implemented as an algebraic data type) that describes the UI and then have an interpreter that constructs everything on the screen. This hides all the state within the interpreter, which makes it easier to avoid issues with the borrow checker. The OP didn't discuss this approach either.