Re: Idea for better function callbacks (another syntactic sugar)
| From: | Crocodile | Date: | Fri, 26 Oct 2018 19:58:26 +0000 |
| Subject: | Re: Idea for better function callbacks (another syntactic sugar) | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-103398@lists.php.net to get a copy of this message | ||
That sounds like a plan, and if there is a reasonable support for that,
then we could just have array_filter($arr, trim) - then its way better than
my proposal, and should also work with class methods.
On Fri, Oct 26, 2018 at 6:03 PM Levi Morrison <levim@php.net> wrote:
> On Fri, Oct 26, 2018 at 9:57 AM Kalle Sommer Nielsen <kalle@php.net>
> wrote:
> >
> > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield <
> larry@garfieldtech.com>:
> > > I believe the proposal for short lambas (which should get resurrected
> at some
> > > point) would handle this case well enough as well as help a dozen other
> > > things. To wit:
> > >
> > > array_filter($names, |$x| ==> trim($x))
> >
> > I still fail to see why it would be considered to have that over a
> > perfectly encapsulted string for a callback, using a lambda/closure is
> > just an extra runtime call for syntax sugar, that seems poor in my
> > eyes.
> >
> > What would be ideal here, would be for functions to be first class
> > citizens in callback contexts, like in C to avoid the quotation,
> > however it clashes with constants. A hack you can do in userland could
> > be something like:
> >
> > const trim = 'trim';
> > array_filter($names, trim);
>
> In my opinion "ideal" here is that our symbol tables are merged, so
> referring to "trim" in any context will resolve to at most one symbol,
> *and* that we also have a short-closure syntax for times when there
> isn't a *perfect* function to use.
>
> In the next version of PHP I would really like to see some warnings
> for when symbol names get re-used so that in the future we can merge
> them with less of a BC break.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
Best regards,
Victor Bolshov