Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114971
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com>
Date: Sat, 19 Jun 2021 04:22:08 -0400
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <37A59CDF-D3C7-4B3D-B389-CF2D9052C8FF@newclarity.net>
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAEPJdukQ4fgsbPtXrVWr-WJDF+8=YzfCgwhs0SnvfjeLvHKriQ@mail.gmail.com>
To: Benjamin Eberlei <kontakt@beberlei.de>
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: mike@newclarity.net (Mike Schinkel)

> On Jun 18, 2021, at 7:41 PM, Benjamin Eberlei <kontakt@beberlei.de> =
wrote:
>=20
> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield =
<larry@garfieldtech.com>
> wrote:
>=20
>> Hi folks.  The vote for the Partial Function Application RFC is now =
open,
>> and will run until 30 June.
>>=20
>> https://wiki.php.net/rfc/partial_function_application
>=20
> I wanted to explain my no vote on this one.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.=20

Just to offer a counter perspective since the assertion was made that =
partial functions would be hard for beginners.

I believe beginners will have a harder time comprehending closures, and =
especially short closures, than partial functions. And especially for =
the use-cases which are likely to be more common, none of which are any =
more "functional" in nature than PHP already is. The use-cases I think =
will be more common? Calling any of the existing built-in PHP functions =
that accept a callable as a parameter.

I am no expert on beginners but I did teach beginning programmers in a =
classroom setting for a decade. One of the biggest stumbling blocks I =
have found for beginners is excessive syntax that looks complex. Many of =
the concepts themselves are less difficult for beginners to understand. =20=


So, in my experience it will be easier for newbies to understand this, =
for example:

	array_map( $this->sanitize_value(?), $values );

Rather that this:

	array_map( fn($value) =3D> $this->sanitize_value($value), =
$values );

The latter just has more sigils to grok than the former, and from what =
I've seen with newbies when you throw too many sigils at them they =
quickly move into a learned helpless state and think that it will be too =
complicated for them to understand.

Bottom line though, what I am saying about newbies is just my opinion =
and probably biased by my own personal sensibilities.=20

If we want to consider how beginners will grok new features we should =
probably find a way to solicit objective feedback from beginners to =
consider in RFCs. Otherwise I fear each of us may just be assuming that =
beginners have the same sensibilities as we do.=20

-----

And where most of us would be still using strings for function =
callables, the benefit of PFA for non-beginners is they let us use =
symbols to aid refactoring, static analysis, IDE functionality, etc.:

	array_map( intval(?), $values );

Rather than:

	array_map( 'intval', $values );

Of course we could use this, but seriously how many of us are using the =
following structure rather than just passing the function name as a =
string?

	array_map( fn($value) =3D> intval($value), $values );


> 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.

For the record, my gut tells me beginners will not grok the proposed =
pipe operator as easily as I think they will partial functions.  But who =
actually knows for sure how newbies will comprehend pipes?

-Mike
>=20