Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114970
MIME-Version: 1.0
In-Reply-To: <CACwt+Jd9SU18vZPqVSt6PPUWxg4tqft6QfCUTW+T8Dv-r4NQ0w@mail.gmail.com>
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com> <CACwt+Jd9SU18vZPqVSt6PPUWxg4tqft6QfCUTW+T8Dv-r4NQ0w@mail.gmail.com>
Date: Sat, 19 Jun 2021 10:39:19 +0500
Message-ID: <CAC_PL4wGFFK94=ad-faknTG0arX9_GVJPUX+9RK9qdSUedyZtQ@mail.gmail.com>
To: Patrick ALLAERT <patrickallaert@php.net>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: office.hamzaahmad@gmail.com (Hamza Ahmad)

HI Larry Garfield,

Do you have a plan to further extend this rfc? I mean, what if one
could typecast place holders? Broadly speaking, what if one could
perform some operations, such as arithmetic, bitwise, and type cast as
said above?

`$foo =3D bar((type) ?);`
`$foo =3D bar(? & 0xFF);`

Best
Hamza Ahmad

On 6/19/21, Patrick ALLAERT <patrickallaert@php.net> wrote:
> 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
>> > 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 i=
f
>> you mirror the typehints), these extra symbols feel necessary from my PO=
V
>> to make the code clear that creates a partial.
>>
>> Especially the ... as "additional" arguments and its various interaction=
s
>> with ? produce so many different ways of calling something, it feels
>> unnecessary to me to introduce this complexity to newbies that might com=
e
>> 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.
>>
>
> 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
>