On Mon, 28 Jun 2021, 18:49 Levi Morrison, <levi.morri...@datadoghq.com> wrote:
> 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. > Right. So you'd have to add a resolve sympol type routine, and if it returns "this is a function/method", strlen would evaluate to be wrapped in a lambda? Then the problem would be the overall performance cost of such a routine, and to deal with collisions, as you said. Hm. Well, couldn't another alternative be that pipe operator assumes a callable it can wrap on its right side? This wouldn't allow the array map use case, but it would allow others. A third alternative would be to type-cast to callable, perhaps. array_map((callable) strlen, $arr); This would be a shorter version of manually writing out the wrapping lambda. But there's already fn, so. No big benefit. Olle
