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 > > 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 > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
