3 ms·

Some are suggesting that the author is against the use of tagged unions. I don't read it that way. What the author is against is using parameters for the speci

Some are suggesting that the author is against the use of tagged unions. I don't read it that way. What the author is against is using parameters for the specific purpose of controlling the flow of a function. Instead, the author recommends breaking the function up into as many functions as there are variants of the type key. This also applies to boolean flags (where only two variants are possible). There are, of course, exceptions as the author points out. The small win is that the type key no longer needs to be maintained. The big win is that each function that gets split out has fewer reasons to change. The individual functions are therefore easier to maintain and understand.

dragonwriter 4y ago
> Some are suggesting that the author is against the use of tagged unions. > I don't read it that way. What the author is against is using parameters for the specific purpose of controlling the flow of a function. Instead, the author recommends breaking the function up into as many functions as there are variants of the type key. Sure. How do you call the right one of the combined set of functions? A conditional branching on the type key at the call site? But then, by the same rule, the calling function should be split into multiple functions instead, and that recursisvely happens until you reach each point an instance of the typed union that might, ever, be passed (indirectly) to the function at issue is defined. And then you have a bunch of sets of near-identical functions where every function in the set needs updated for any required change that doesn’t depend on the tagged union. And the tagged union is no longer really serving the purpose of a tagged union, which is exactly to allow not having that kind of duplication.
- Fellshard 4y ago
  I think the idea is that it's better to maintain several functions whose implementations are each linear flow than to maintain a single function that is littered with type key checks to turn on and off parts of its flow. It's trading off comprehension of each function by adding some risk that those functions will have shared parts that go out of sync.
- deleted 4y ago
  [deleted]
motogpjimbo 4y ago
> The big win is that each function that gets split out has fewer reasons to change. The individual functions are therefore easier to maintain and understand. Yet the namespace becomes more polluted and the interconnections between the functions becomes more complicated, particularly during debugging. It's important to remember that "break big things into smaller things" only pushes complexity someone else rather than eliminating it altogether, while simultaneously increasing the overall complexity of the system by increasing the number of interconnections between the parts. That doesn't mean you shouldn't do it but you should be honest about the consequences.

dragonwriter 4y ago

> Some are suggesting that the author is against the use of tagged unions. > I don't read it that way. What the author is against is using parameters for the specific purpose of controlling the flow of a function. Instead, the author recommends breaking the function up into as many functions as there are variants of the type key. Sure. How do you call the right one of the combined set of functions? A conditional branching on the type key at the call site? But then, by the same rule, the calling function should be split into multiple functions instead, and that recursisvely happens until you reach each point an instance of the typed union that might, ever, be passed (indirectly) to the function at issue is defined. And then you have a bunch of sets of near-identical functions where every function in the set needs updated for any required change that doesn’t depend on the tagged union. And the tagged union is no longer really serving the purpose of a tagged union, which is exactly to allow not having that kind of duplication.

Fellshard 4y ago
I think the idea is that it's better to maintain several functions whose implementations are each linear flow than to maintain a single function that is littered with type key checks to turn on and off parts of its flow. It's trading off comprehension of each function by adding some risk that those functions will have shared parts that go out of sync.
deleted 4y ago
[deleted]

motogpjimbo 4y ago

> The big win is that each function that gets split out has fewer reasons to change. The individual functions are therefore easier to maintain and understand. Yet the namespace becomes more polluted and the interconnections between the functions becomes more complicated, particularly during debugging. It's important to remember that "break big things into smaller things" only pushes complexity someone else rather than eliminating it altogether, while simultaneously increasing the overall complexity of the system by increasing the number of interconnections between the parts. That doesn't mean you shouldn't do it but you should be honest about the consequences.