On Tue, May 5, 2020 at 9:11 AM Marco Pivetta <ocram...@gmail.com> wrote:
> As mentioned some days ago, I see named parameters as an added liability,
> rather than values.
> The rationale of my negativity around the topic being that a diff like
> following is now to be considered a BC break:
>
> ```diff
> -function foo($parameterName) { /* ... */ }
> +function foo($newParameterName) { /* ... */ }
> ```
If the function is part of your own codebase, an IDE can automatically
update function calls when renaming a parameter. For functions that are
part of a public API, yes, parameters shouldn't be renamed outside of
major versions. But in my experience, it's rare for function parameters
that are part of public APIs to be renamed. Do you have many real-world
examples of where this had to happen?
Also, I haven't heard of this being a big problem in other languages
with named arguments like Python.
> the feature seems to be especially designed to work with particularly
> bad API (anything with a gazillion optional parameters, such as all
> the OpenSSL nightmares in php-src).
Why do you say that? For me this feature would be extremely helpful
when calling constructors that have several optional arguments (e.g.
similar to the `ParamNode` example in the RFC). Maybe you consider
this a bad API, but it's a very common pattern, and named arguments
will make it far easier to work with than the typical alternative of
converting arguments to an options array (which is itself a BC break
and has many other downsides as the RFC points out).
> In practice, the issues around bad API (in this case, bad = lots of
> optional parameters, maybe even ordered arbitrarily) are fixed by
> using proper value types and structs or value objects
How can lots of optional parameters be "fixed" in practice with structs?
E.g. how would they improve the `ParamNode` example in the RFC? Would
it even be possible to migrate existing classes like this to structs
without a BC break?
Personally I think it's a lot simpler and more consistent to have named
arguments which can be used anywhere, including in attributes, vs.
having to implement and learn a new syntax for structs which only works
for that one use case (and may not be easy to migrate to).
Best regards,
Theodore Brown
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
