Le sam. 19 juin 2021 à 01:41, Benjamin Eberlei <kont...@beberlei.de> a écrit :
> 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. > 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
