3 ms·
>The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching. Why do you think this? I
by runT1ME 13y ago
>The expression problem is much safer solved using virtual classes (using traits and type members) in scala than with case matching.
Why do you think this? I prefer having an open trait that's only inherited by ADTs.
I can get non-exhaustive match warnings and I still 'solve' the expression problem by matching on a superset of my partial functions (that do the matching).
- seanmcdirmid 13y agoVirtual classes with family polymorphism attacks the problem directly: you can add new variants as well as enhance the super class with new abstract methods: your system is abstract until all variants have implemented the abstract methods of the super class. You can then do cool things like factor all your functionality for X in one layer and Y in another layer, replicating variants in X and Y layers to specify their implementations separately. When I did this in Scala (using traits and type parameters in a virtual class pattern), I got a lot of pushback from the FP people, who thought this problem couldn't, or more correctly SHOULDN'T, be solved using object-oriented constructs; it was one of the main things they liked to boast about in how FP was better than OOP, and I literally took that away from them. A 10,000 line pattern match was somehow preferable to a file with 20 traits that described how the new operation was performed per variant. Martin even made my pattern illegal via a new type check in the Scala compiler after I left EPFL :)