On Tue, May 5, 2020 at 4:11 PM Marco Pivetta <ocram...@gmail.com> wrote:
> Hey Nikita, > > On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita....@gmail.com> wrote: > > > Hi internals, > > > > I've recently started a thread on resurrecting the named arguments > proposal > > (https://externals.io/message/109549), as this has come up tangentially > in > > some recent discussions around attributes and around object ergonomics. > > > > I've now updated the old proposal on this topic, and moved it back under > > discussion: https://wiki.php.net/rfc/named_params > > > > Relative to the last time I've proposed this around PHP 5.6 times, I > think > > we're technically in a much better spot now when it comes to the support > > for internal functions, thanks to the stubs work. > > > > I think the recent acceptance of the attributes proposal also makes this > a > > good time to bring it up again, as phpdoc annotations have historically > had > > support for named arguments, and this will make migration to the > > language-provided attributes smoother. > > > > 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) { /* ... */ } > ``` > > In addition to that, 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). > I see the PHP internal API as the main benefactor of this feature over userland code imho. Internals realistically couldn't get "smaller APIs" without adding many new functions instead, for example htmlspecialchars. The trade off from API design perspective is either providing a more complex API by having function permutations or an OOP API, which in turn developers have more trouble remembering. Or the more beginner approachable way is providing a single function that is easy to remember exists, but in turn does more things and may require a look into the documentation to see all the options. Given we have this API already in PHP and this will not realistically change, I think named params will be a big win. > In practice, the issues around bad API (in this case, ba > d = lots of > optional parameters, maybe even ordered arbitrarily) are fixed by using > proper value types and structs or value objects: > > ```php > myHorribleLegacyAndOrganicallyGrownApi( > > > ...MyInfiniteSequenceOfParametersAsProperValidatedStructure::fromArray($stuff) > ->toSequentialParameters() > ); > ``` > > For the few use-cases where this is needed, the userland solution seems to > be sufficient, without introducing catastrophic BC boundary expansions. > In this example $stuff is an array which has keys. Presumably $parameterName => $newParameterName would be equivalent to a change of key names. Or property names on MyInfiniteSequenceOfParametersAsProperValidatedStructure. So you get the BC break of renaming anyways in your example. Now as a provider of a public API (library, framework) you can still counter this with a BC layer: function foo($newParameterName, $parameterName = null) { if ($parameterName !== null) { $newParameterName = $parameterName; trigger_error("Using paramaterName as named parameter is deprecated, use newParameterName instead.", E_USER_DEPRECATED); } /... } this looks ugly (because we haven't seen it before), but is not more or less complex than the same BC / deprecation layer in fromArray with changed option: public static function fromArray(array $options) { if (isset($options['parameter_name'])) { $options['new_parameter_name'] = $options['parameter_name']; trigger_error("Using paramaeter_name as option is deprecated, use new_parameter_name instead.", E_USER_DEPRECATED); } } So nothing much would technically change for someone who cares about BC for their users. > > > Unless I'm not seeing an incredible (hidden, to me) value from this > functionality, this is a clear -1 from me. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/
