Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114968
MIME-Version: 1.0
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
In-Reply-To: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
Date: Sat, 19 Jun 2021 01:41:03 +0200
Message-ID: <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000000851905c512dcbe"
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: kontakt@beberlei.de (Benjamin Eberlei)

--00000000000000851905c512dcbe
Content-Type: text/plain; charset="UTF-8"

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 open,
> 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 that,
> as Nikita explained off-list it was actually more confusing, not less, as
> it would suggest "placeholder for a variadic" rather than "a placeholder
> that is variadic."  Otherwise, it's just more typing.  The syntax choices
> 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 using
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 delayed
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 the
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 proposes
to do a thing (calling functions) in a completly new way that will be hard
for beginners. I hope we don't add both these features to keep the language
smaller in this aspect of how functions are called.


> --
>   Larry Garfield
>   larry@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--00000000000000851905c512dcbe--