Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110006
User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1
Mime-Version: 1.0
Message-ID: <d54d3a5f-edf7-4bd3-92ce-f3cdc74631bc@www.fastmail.com>
In-Reply-To: 
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
References: 
 <CAF+90c8m-CB3ZxAHeoOJVxJGhysLfZqpz3mq475GPnMEDA6iqQ@mail.gmail.com>
 <CADyq6s+pfDfDey8hGT=zDD5hwyKjq3q6V8xPVyP03z=6MwGgdQ@mail.gmail.com>
Date: Tue, 05 May 2020 10:28:51 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Named arguments
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 5, 2020, at 9:11 AM, Marco Pivetta 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).
> 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:
> 
> ```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.
> 
> Unless I'm not seeing an incredible (hidden, to me) value from this
> functionality, this is a clear -1 from me.

I agree that named params can be used as a crutch for poor API design.  However, that's not always the case.

The biggest use case I see is, as discussed previously, value object constructors.  "Pass an entirely untyped and undocumentable array of parameters" is not an sufficient userland solution in my mind, but is the only available alternative right now.

Attributes, now that those are a thing, are another very good use case, IMO.  The combination of constructor promotion and named params gives us an effective equivalent to structs and struct-creation from Go or Rust or similar languages with a minimum of overhead, allowing for typed, lintable, efficient data structure definitions to more easily replace "big anonymous associative arrays."  Those are way worse than the API abuse named parameters could offer.

I share your concern that it could get abused; so does anything else though, for that matter.  Part of that could be addressed with good documentation and education.  If we had to change the approach, then I would be open to limiting them to constructors as that's where the really big use cases are.  I don't know if that inconsistency would be worse than allowing them everywhere, though.

--Larry Garfield