5 ms·

Seems like a design pattern from Java which often are badly converted functional programming snippets into OOP. I once loved C++, now I can't force myself to re

by bitL 9y ago

Seems like a design pattern from Java which often are badly converted functional programming snippets into OOP. I once loved C++, now I can't force myself to read the code anymore... Please add some monads there to destroy my hope for humanity once for all! I think maintainers of C++ have a case of "functional programming" envy.

dfox 9y ago
Discriminated union is low-level pattern from non-OO languages (it is common pattern in C, Pascal has syntax for this and IIRC unions are always discriminated in "standard" Pascal) In object oriented languages this pattern is mostly unnecessary, because inheritance is usually better solution for the same problem. Only reason to use something like this in C++ is (maybe even only perceived) efficiency gained by removing level of pointer indirection.
- xyzzyz 9y ago
  The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former. It really comes from functional languages like ML, and is extremely useful and convenient when combined with pattern matching. In fact, attempts to emulate it in OOP using interfaces and visitor pattern tend to bring a lot of boilerplate, and obscure the actual logic, which is exactly what the author is complaining about. There's definitely more reason to use it than just "efficiency gain", which is why many languages introduced in the last decade have it built in (e.g. Rust, Scala or Swift).
  - mcphage 9y ago
    > The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former. Could you say something about the difference between the two? I'm not aware what it is. Edit: wow I accidentally a word.
    - mrkgnao 9y ago
      IIRC discriminated unions are plain C(++) unions with an added type tag, like at the beginning of the article. Brittle, prone to breakage when refactoring, etc. when compared to real sum types.
  - Koshkin 9y ago
    Actually, the article says, "A sum type, also called a discriminated union..."
- Wilduck 9y ago
  I'm really curious, I write a lot of python, and find myself wishing for sum types all the time. How do you see inheritance filling the same space? I'd love to be able to do something like: data Choices = Good | Bad | Ugly like I can do in haskell, where a value of type `Choices` can only ever be one of those options. But there doesn't seem to be any reasonable approximation in python.
  - Ded7xSEoPKYNsDd 9y ago
    The OOP pattern dfox is referring to would look something like this: class AbstractChoice: # defines all common operations on choices # plus potentially some useful stuff on top of those pass class Good(AbstractChoice): # conatins the code specific to good things pass class Bad(AbstractChoice): pass class Ugly(AbstractChoice): pass This isn't a straight-on replacement though. It's especially bad when you want to separate your concerns not along the good-bad-ugly-axis but something different (which is when you'd e.g. go on to use mixins, or that ugly visitor pattern we've seen in the OP).
deleted 9y ago
[deleted]
alkonaut 9y ago
They should have FP envy if their language doesn't have a simple and clean looking way of defining that a value is either a T or a U. Inheritance in the normal sense doesn't cut it because that defines an open (for extension) set of subtypes. You can't e.g compile time check that a switch/match has tested all cases. If you want to make a closed set of subtypes that's usually possible only by writing a class hierarchy with private subtypes and an abstract outer type with factory methods for the inner types. That takes hundreds of lines for even just a couple of variants, and then there is still no compiler help for exhaustive switch/match.
- bitL 9y ago
  Why should C++ as an imperative/OOP language ape everything possible in FP? It feels like when FP languages slap on OOP for a change. C++ wasn't designed with what we call FP these days in mind, so unless it's going to change drastically, there will always be "smell". FP doesn't have many things C++/D etc. have. Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?
  - tree_of_item 9y ago
    Sum types are not "everything possible in FP". I'm part of the group that views sums as an extremely basic language feature and I give an extreme side-eye to any language that still doesn't have them in the current year.
    - masklinn 9y ago
      > I'm part of the group that views sums as an extremely basic language feature More importantly it's the second category of type relations. There are product types and there are sum types, if you only have product types, you're missing an entire half of expressible type relations/compositions. It's not a matter of functional versus imperative, there's nothing inherently functional about sum types.
      - infinite8s 9y ago

by bitL 9y ago

dfox 9y ago

Discriminated union is low-level pattern from non-OO languages (it is common pattern in C, Pascal has syntax for this and IIRC unions are always discriminated in "standard" Pascal) In object oriented languages this pattern is mostly unnecessary, because inheritance is usually better solution for the same problem. Only reason to use something like this in C++ is (maybe even only perceived) efficiency gained by removing level of pointer indirection.

xyzzyz 9y ago
The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former. It really comes from functional languages like ML, and is extremely useful and convenient when combined with pattern matching. In fact, attempts to emulate it in OOP using interfaces and visitor pattern tend to bring a lot of boilerplate, and obscure the actual logic, which is exactly what the author is complaining about. There's definitely more reason to use it than just "efficiency gain", which is why many languages introduced in the last decade have it built in (e.g. Rust, Scala or Swift).
- mcphage 9y ago
  > The sum type, which the author is talking about, is not the same as "discriminated union" pattern, the latter being the crude implementation of the former. Could you say something about the difference between the two? I'm not aware what it is. Edit: wow I accidentally a word.
  - mrkgnao 9y ago
    IIRC discriminated unions are plain C(++) unions with an added type tag, like at the beginning of the article. Brittle, prone to breakage when refactoring, etc. when compared to real sum types.
- Koshkin 9y ago
  Actually, the article says, "A sum type, also called a discriminated union..."
Wilduck 9y ago
I'm really curious, I write a lot of python, and find myself wishing for sum types all the time. How do you see inheritance filling the same space? I'd love to be able to do something like: data Choices = Good | Bad | Ugly like I can do in haskell, where a value of type `Choices` can only ever be one of those options. But there doesn't seem to be any reasonable approximation in python.
- Ded7xSEoPKYNsDd 9y ago
  The OOP pattern dfox is referring to would look something like this: class AbstractChoice: # defines all common operations on choices # plus potentially some useful stuff on top of those pass class Good(AbstractChoice): # conatins the code specific to good things pass class Bad(AbstractChoice): pass class Ugly(AbstractChoice): pass This isn't a straight-on replacement though. It's especially bad when you want to separate your concerns not along the good-bad-ugly-axis but something different (which is when you'd e.g. go on to use mixins, or that ugly visitor pattern we've seen in the OP).

deleted 9y ago

[deleted]

alkonaut 9y ago

They should have FP envy if their language doesn't have a simple and clean looking way of defining that a value is either a T or a U. Inheritance in the normal sense doesn't cut it because that defines an open (for extension) set of subtypes. You can't e.g compile time check that a switch/match has tested all cases. If you want to make a closed set of subtypes that's usually possible only by writing a class hierarchy with private subtypes and an abstract outer type with factory methods for the inner types. That takes hundreds of lines for even just a couple of variants, and then there is still no compiler help for exhaustive switch/match.

bitL 9y ago
Why should C++ as an imperative/OOP language ape everything possible in FP? It feels like when FP languages slap on OOP for a change. C++ wasn't designed with what we call FP these days in mind, so unless it's going to change drastically, there will always be "smell". FP doesn't have many things C++/D etc. have. Should we insist on every FP to have assembly-level access, custom memory managers etc. because they are cool as well?
- tree_of_item 9y ago
  Sum types are not "everything possible in FP". I'm part of the group that views sums as an extremely basic language feature and I give an extreme side-eye to any language that still doesn't have them in the current year.
  - masklinn 9y ago
    > I'm part of the group that views sums as an extremely basic language feature More importantly it's the second category of type relations. There are product types and there are sum types, if you only have product types, you're missing an entire half of expressible type relations/compositions. It's not a matter of functional versus imperative, there's nothing inherently functional about sum types.
    - infinite8s 9y ago