On Tue, May 5, 2020 at 8:22 PM Nikita Popov <nikita....@gmail.com> wrote:
> Builders and withers? Those are not, intrinsically, good code. They are > workarounds for lack of good object initialization support. I should not > have to implement a large amount of builder boilerplate to make the > construction of simple objects safe and ergonomic. We're not talking about > some kind of complex multi-stage construction logic here, but the > construction of what essentially amounts to a value object. > They are not good code, but they are reasonable code, in which each call is an atomic state creation/mutation. Generally, named arguments really change what constitutes a good API and > what doesn't. Things like boolean flags to functions are considered bad > design *because* we do not have named arguments. If I pick out some random > Python API, say subprocess.run()... > You got multiple APIs within a single massive signature: may as well start counting the permutations of possible characters you pass to an endpoint, and what you get in the end is `eval()` :-P > subprocess.run(args, *, stdin=None, input=None, stdout=None, > stderr=None, capture_output=False, shell=False, cwd=None, timeout=None, > check=False, encoding=None, errors=None, text=None, env=None, > universal_newlines=None) > > ... and show that to a PHP developer, they're probably going to tell me > that this is horrible API design. They would, of course, be wrong. It's > reasonable API design, just in a language that supports named arguments. > There are so many ways in which the above fails in different ways (besed on flags) that I can't even start to reason about the resulting chaos. Would rather consume a dozen of differently named (curried) versions of this. Similar to the above: might as well uncurry all the defined API of a program into a single `function (string, array $args)` (which is what the PHP engine or CPUs doe at low-level, obviously).
