4 ms·

> Just ugliness and typical boilerplate heavy approach of JVM languages. I have provided a case how using inheritance to express sum types can help in the use

• wiseowise 1y ago
  Kotlin's/Java's implementation is just a poor man's implementation of very restricted set of real sum types. I have no idea what > This has the benefit of giving you the ability to refer to a case as its own type. means.
  • ackfoobar 1y ago
    > I have no idea I can tell. Thankfully the OCaml textbook has this explicitly called out. https://dev.realworldocaml.org/variants.html#combining-records-and-variants https://dev.realworldocaml.org/variants.html#combining-recor... > The main downside is the obvious one, which is that an inline record can’t be treated as its own free-standing object. And, as you can see below, OCaml will reject code that tries to do so.
    • wiseowise 1y ago
      That's for embedded records. You can have the same thing as Kotlin but with better syntax.
      • ackfoobar 1y ago
        If you don't do inline records you either - create a separate record type, which is no less verbose than Java's approach - use positional destructuring, which is bug prone for business logic. Also it's funny that you think OCaml records are "with better syntax". It's a weak part of the language creating ambiguity. People work around this qurik by wrapping every record type in its own module. https://dev.realworldocaml.org/records.html#reusing-field-names https://dev.realworldocaml.org/records.html#reusing-field-na...