It could be indeed. In fact, I have a different implementation in Clojure which is not OO. It’s just functional. Although Clojure’s Scheme-like nature, makes it easy to implement ad-hoc application specific object systems. In fact it could be implemented in many different languages under different constraints.
My goal in Scala is not to avoid OO. In my mind, a strength of OO is that you can write abstract code when you don’t have all the information you need, and fill in the details as classes become more specific. If a particular computation needs to be done in the same way for a certain class of objects, you can encode that easily and once, for some definition of easily.
This isn’t about avoiding OO at all. It’s about pragmatically going with the language when you hit a roadblock with your intended design.
As said before, there’s nothing wrong with your approach (and you can easily find examples for it in the std lib). But now you’ve found you have an issue with the source file size triggered by the sealed trait constraints. At this point, I see the following options:
Just live with the huge (and potentially growing) file.
Rework the design toward ADT/pattern matching. (Either completely, or keeping some “core” methods in the ADT.)
Drop the sealed trait, rely on test cases for “exhaustiveness” checking.
Introduce additional complex structure obscuring the code, exclusively for working around the single-file requirement.
I’d probably go with the ADT choice, although it really depends on the specifics of the concrete case. But I have a hunch what my least favorite choice might be.
Hi, @jimka I just published this as an attempt to condense everything that was discussed here and in the other thread in a single tutorial for future reference.
