Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114969
MIME-Version: 1.0
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com> <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com>
In-Reply-To: <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com>
Date: Sat, 19 Jun 2021 02:15:54 +0200
Message-ID: <CACwt+Jd9SU18vZPqVSt6PPUWxg4tqft6QfCUTW+T8Dv-r4NQ0w@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a700a505c5135804"
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: patrickallaert@php.net (Patrick ALLAERT)

--000000000000a700a505c5135804
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Le sam. 19 juin 2021 =C3=A0 01:41, Benjamin Eberlei <kontakt@beberlei.de> a
=C3=A9crit :

> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
>
> > Hi folks.  The vote for the Partial Function Application RFC is now ope=
n,
> > and will run until 30 June.
> >
> > https://wiki.php.net/rfc/partial_function_application
> >
> > Of particular note, a few people had asked about using ...? instead of
> ...
> > for the variadic placeholder.  In the end we decided not to explore tha=
t,
> > as Nikita explained off-list it was actually more confusing, not less, =
as
> > it would suggest "placeholder for a variadic" rather than "a placeholde=
r
> > that is variadic."  Otherwise, it's just more typing.  The syntax choic=
es
> > section of the RFC has been updated accordingly.
> >
>
> I wanted to explain my no vote on this one.
>
> The examples section shows how every use-case of partials can be done usi=
ng
> short functions and while this is often a lot more to type (especially if
> you mirror the typehints), these extra symbols feel necessary from my POV
> to make the code clear that creates a partial.
>
> Especially the ... as "additional" arguments and its various interactions
> with ? produce so many different ways of calling something, it feels
> unnecessary to me to introduce this complexity to newbies that might come
> across use of this functionality. Plus the additional edge cases of delay=
ed
> execution, non-support for named parameters. Its a lot to know to fully
> understand this feature.
>
> Given that the functional paradigm isn't widely spread in use across PHP
> developers, i am not convinced that we should add more features in this
> direction that increase the complexity of understanding the language by
> that much. While one could argue that functional paradigm isn't
> wide-spread, because these features are missing, it is my believe that th=
e
> majority of PHP developers would still rather prefer imperative coding.
>
> As a thought experiment I tried to think of code in our codebase that we
> could convert to PFA once we migrated to 8.1 and there just isn't that
> much. This is very different to short functions, nullabilty operator and
> other "glue" / sugar proposals that were added to the language lately,
> which a lot of existing code benefits from and existing code could be
> converted automatically to them using phpcs/phpcbf rules.
>
> I also am wary of the future after this RFC, as it states it is the
> launching pad to another attempt at the Pipe Operator, which also propose=
s
> to do a thing (calling functions) in a completly new way that will be har=
d
> for beginners. I hope we don't add both these features to keep the langua=
ge
> smaller in this aspect of how functions are called.
>

I second Benjamin's opinion, hence my choice of voting "no" as well.

Every new feature we add adds an extra layer of complexity in an
exponential way, next new features/syntax have to deal with existing ones.
The problem being solved with PFA, including how frequent it could be
useful in PHP's ecosystem, does not, IMHO, counterbalance with the
increased code complexity.

-Patrick

--000000000000a700a505c5135804--