Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110008
MIME-Version: 1.0
References: <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
In-Reply-To: <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
Date: Tue, 5 May 2020 17:44:40 +0200
Message-ID: <CAEPJdunAY1taDC3oR+3faUj5wfFxAGVTC41G8=WkA-qfG1HrDw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003a3e0205a4e88705"
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000003a3e0205a4e88705
Content-Type: text/plain; charset="UTF-8"

On Tue, May 5, 2020 at 4:11 PM Marco Pivetta <ocramius@gmail.com> wrote:

> Hey Nikita,
>
> On Tue, May 5, 2020 at 3:51 PM Nikita Popov <nikita.ppv@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/

--0000000000003a3e0205a4e88705--