> On Jun 18, 2021, at 7:41 PM, Benjamin Eberlei <kont...@beberlei.de> wrote:
>
> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield <la...@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
>
> 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.
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.
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) => $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.
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.
-----
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) => 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
