On Mon, Jun 28, 2021 at 10:32 AM Olle Härstedt <olleharst...@gmail.com> wrote: > > On Thu, 24 Jun 2021, 18:02 Larry Garfield, <la...@garfieldtech.com> wrote: > > > On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield 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. > > > > Since some people still don't grok the use cases, I've written a blog post > > to make the case for them better than a detail-oriented RFC can. > > > > https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-php > > > > There has also been some positive Twitter chatter, as well as the level of > > +1s on that post (which is, I think, the highest of any PHP post I've had > > on there, ever), so I think the demand for it is definitely there in the > > ecosystem. It's just not people who frequent Internals. :-/ > > > > I'd say there are definitely people that want to use partials. > > > > --Larry Garfield > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > Out of curiosity, what would it take to implement function aliasing in PHP? > To enable a limited form of pipes, like `foo |> bar`. > > Olle
We probably could special case it for pipes; it's more of a matter if we _should_. But, to do it generally so that things like `array_map(strlen, $arr)` work is not trivial. The main issue is that different symbol types have separate "tables", if you will. The engine decides to look in one bucket or another based on the syntax. In this case, based on syntax the engine will look in the constant table for `strlen`, as `strlen` in `array_map(strlen, $arr)` is a constant lookup by syntax. If we want it to fall-back to looking in other tables, then we'd have to deal with various challenges: 1. We have to deal with symbol collisions that exist today somehow, such as if `strlen` exists both as a function and a constant, or if `$this->count` exists as both a property and a method. I would prefer to do the simple thing and forbid collisions, but there are other strategies. 2. How do we handle the fact that different symbol types behave differently in namespaces when the symbol doesn't exist? 3. Also, how do we handle differences in case sensitivity between symbol types? Personally, I think it's worth it to change all of these things, because it could also give us function and constant autoloading. Of course, we'd have to get 2/3 of voters to agree on solutions to these things, which probably includes some backward-compatibility breaks so that might be difficult. But, nobody has tried so maybe not. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
