Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110919
MIME-Version: 1.0
References: <CAF+90c_DPYqzOH1TU2mrG7cjh87RNXEzMx3hAAeDRfbTPpGVvw@mail.gmail.com>
 <CADyq6sL16QTzCe5=60oVDfLkAd8s_udBkKQPbc6_8MtRW_+rYw@mail.gmail.com>
In-Reply-To: <CADyq6sL16QTzCe5=60oVDfLkAd8s_udBkKQPbc6_8MtRW_+rYw@mail.gmail.com>
Date: Fri, 10 Jul 2020 16:18:40 +0200
Message-ID: <CAEPJdukyHNneTimTriXPSqhvgCqz8Ujvpferv3NSfu+9Xa46cw@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="00000000000035df5005aa17058c"
Subject: Re: [PHP-DEV] [VOTE] Named arguments
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000035df5005aa17058c
Content-Type: text/plain; charset="UTF-8"

On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta <ocramius@gmail.com> wrote:

> Hi Nikita,
>
> I kept my "NO" stance here, as per discussion in
> https://externals.io/message/110004#110005, where I provided (in my
> opinion) good/safe alternatives to arrays as input parameters.
>

> The BC implications on this RFC still largely outweigh any advantages that
> it brings, from my perspective.
>

Are there alternatives to named parameters? Of course. Are they as simple?
Not really.

1. You can use an array, but array values cannot be typed, so you completly
loose typing of the language.
2. You can use an object with builder pattern, but that requires a lot of
code to write, and increases the mental capacity of understanding something
for developers.
3. your example of an api to convert named params to a sequence is not
discoverable, you don't know looking or using method A() that it comes with
an additional NamedParamsA() helper.

I see PHP as a language to get up and running quickly. So builder pattern
is really more an advanced approach, should be used by not many use-cases.
We have seen
arrays of $options and $params to no end in framework and library APIs,
with all their problems.

So named params are a real improvement that feels like supporting "the php
way(tm)".

Lastly we need to consider internal APIs, which are usually about adding
more parameters (htmlentities, json_decode, ...). These APIs are going to
stay and benefit hugely from named params.

Then the question becomes, do we rename parameters a lot? I doubt it's a
large problem, and even then the variadics support makes it very easy to
handle in a backwards compatible way. In addition libraries are always open
to declare they don't consider named parameters as part of their API.



> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov <nikita.ppv@gmail.com>
> wrote:
>
> > Hi internals,
> >
> > I have opened voting on the named arguments RFC:
> > https://wiki.php.net/rfc/named_params
> >
> > Voting will close on 2020-07-24.
> >
> > Regards,
> > Nikita
> >
>

--00000000000035df5005aa17058c--