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 = bar((type) ?);` `$foo = bar(? & 0xFF);` Best Hamza Ahmad On 6/19/21, Patrick ALLAERT <patrickalla...@php.net> wrote: > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
