4 ms·

Ad-hoc polymorphism is valuable, and objects represent a clear way to express it You can do ad-hoc polymorphism using type boxes (existentially quantified type

Ad-hoc polymorphism is valuable, and objects represent a clear way to express it You can do ad-hoc polymorphism using type boxes (existentially quantified type classes). Of if you think this is an anti-pattern, just plain old data structures plus (first-class) functions: https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ https://lukepalmer.wordpress.com/2010/01/24/haskell-antipatt... Thin wrappers that slightly change functionality are often a business requirement, and "extends" inheritance provides an easy way to express them So does composition. In OO style it's immediately clear what I can do with my user info, because it's all methods on the object The problem with this is discussed in the linked article. Edit: I see that you do Scala, so all of this is not news to you ;).

lmm 11y ago
> So does composition. I've found composition is always much more heavyweight than it should be. "Deriving" helps a bit, but it still feels very manual when your use case is along the lines of "I have this thing with 6 behaviours and now I want a wrapper that changes just one of them very slightly".
- romankolpak 11y ago
  A more practical way of discussing this would be a concrete example of a business need, implemented in both paradigms - object-oriented design relying on inheritence and then a more typical to FP design based on composability. Then by simply comparing the two we could draw some conclusions about code size, simplicity, maintainability and so on.
  - lmm 11y ago
    There's no way to do a small example because it's an issue that only happens when you already have a large codebase. Say you have a large, complex object - and you can argue that's already assuming something about your development path. And then you want to offer a variant that has slightly different behaviour (say it has an extra line when you print it, and one of the calculation methods should return 2x as much for this variant, and another method should return 0.5x as much - and again, that's making intrusive assumptions about the wider design). That kind of scenario really does happen all the time in real-word functional code (at least for me), but it's impossible to make it a rigorous example where partisans can't say "don't do that then".

lmm 11y ago

> So does composition. I've found composition is always much more heavyweight than it should be. "Deriving" helps a bit, but it still feels very manual when your use case is along the lines of "I have this thing with 6 behaviours and now I want a wrapper that changes just one of them very slightly".

romankolpak 11y ago
A more practical way of discussing this would be a concrete example of a business need, implemented in both paradigms - object-oriented design relying on inheritence and then a more typical to FP design based on composability. Then by simply comparing the two we could draw some conclusions about code size, simplicity, maintainability and so on.
- lmm 11y ago
  There's no way to do a small example because it's an issue that only happens when you already have a large codebase. Say you have a large, complex object - and you can argue that's already assuming something about your development path. And then you want to offer a variant that has slightly different behaviour (say it has an extra line when you print it, and one of the calculation methods should return 2x as much for this variant, and another method should return 0.5x as much - and again, that's making intrusive assumptions about the wider design). That kind of scenario really does happen all the time in real-word functional code (at least for me), but it's impossible to make it a rigorous example where partisans can't say "don't do that then".