> To me using default parameters to control behavior in OO languages is insanity. That’s what OO design is for?
But we all went away from this because pure OO is also pitfall riddled and extremely clunky and overly verbose and repetitive at a large scale.
The answer is a more functional style, partial application and immutability solves so much of what people are talking about, but nobody wants to learn to use functional languages.
I'd say partial application solves a different problem than default parameters. Partial application is a convenient way for users of an API to define default behavior (but can easily be emulated by lambdas/closures), whereas default arguments allow API designers to define default behavior.
> The answer is a more functional style, partial application and immutability solves so much of what people are talking about, but nobody wants to learn to use functional languages.
People still use default arguments in functional programming when they can: see for example functions that take a map of arguments that’s merged into a default one.
To me using default parameters to control behavior in OO languages is insanity. That’s what OO design is for?
Or make a “simple” method with a few parameters that calls an “_ex” version with the full set of parameters. (To borrow Microsoft terminology)
Sure, a little extra typing but it separates the common and special cases, perhaps inviting scrutiny on why the nondefault parameters are needed…
Soon after that, one will probably refactor all this away too.