Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Idea for better function callbacks (another syntactic sugar) »

Idea for better function callbacks (another syntactic sugar)

php.internals

Victor Bolshov

7 years ago
Hi internals! I have this idea of improving the way to specify callbacks for good old PHP functions. For instance, I have this piece of code: --------------- array_filter($names, 'trim') --------------- The callback function name is specified as a string, which makes it not-so-obvious, although this is definitely a PHP way. An alternative would be to rewrite this using a lambda: --------------- array_filter($names, function($name) { return trim($name); }) --------------- This is way more wordy, and I bet most of us will go for the first option. What if we had a more clear way of specifying those callbacks? I suggest the following: --------------- array_filter($names, function::trim) --------------- It is, I believe, more clear then a simple string, just a bit more wordy, and since "function" is a reserved word which never had anything to do with "::", the lexer/parser could probably find a way to deal with this kind of syntax (well, honestly, this part is totally unclear for me because I only work with PHP from userland). Does anyone else find this could be a good addition? Or is it not worth considering? Or maybe I am missing some obvious pitfalls? Cheers, Victor
-- Best regards, Victor Bolshov

Larry Garfield

7 years ago
On Friday, October 26, 2018 7:29:46 AM CDT Crocodile wrote:
> Hi internals! > > I have this idea of improving the way to specify callbacks for good old PHP > functions. For instance, I have this piece of code: > > --------------- > array_filter($names, 'trim') > --------------- > > The callback function name is specified as a string, which makes it > not-so-obvious, although this is definitely a PHP way. An alternative would > be to rewrite this using a lambda: > > --------------- > array_filter($names, function($name) { return trim($name); }) > --------------- > > This is way more wordy, and I bet most of us will go for the first option. > > What if we had a more clear way of specifying those callbacks? I suggest > the following: > > --------------- > array_filter($names, function::trim) > --------------- > > It is, I believe, more clear then a simple string, just a bit more wordy, > and since "function" is a reserved word which never had anything to do with > "::", the lexer/parser could probably find a way to deal with this kind of > syntax (well, honestly, this part is totally unclear for me because I only > work with PHP from userland). > > Does anyone else find this could be a good addition? Or is it not worth > considering? Or maybe I am missing some obvious pitfalls? > > Cheers, > Victor
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)) --Larry Garfield

Kalle Sommer Nielsen

7 years ago
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);
-- regards, Kalle Sommer Nielsen kalle@php.net

Levi Morrison

7 years ago
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.

Benjamin Morel

7 years ago
> > In my opinion "ideal" here is that our symbol tables are merged >
I would love to see this as well, as this would make the language much more consistent. Would this allow to array_filter($names, trim), though?

Victor Bolshov

7 years ago
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

Kalle Sommer Nielsen

7 years ago
Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison <levim@php.net>:
> 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.
I like that idea a lot tbh, but I do worry a lot about the lookup time if we end up with a gigantic hashtable to hold all the symbols and the implications it has. In most contexts we know (based on the syntax) what we are looking for, however as it currently stands then it would not be clear wether to look for the constant "trim" or the procedural function "trim" in the example given, and if thats all the same, I can see that many things not utilizing this could be slower for no good reason (at least in my honest opinion). However I don't know if there is something sneaky we can do here.
-- regards, Kalle Sommer Nielsen kalle@php.net

Levi Morrison

7 years ago
On Fri, Oct 26, 2018 at 3:09 PM Kalle Sommer Nielsen <kalle@php.net> wrote:
> > Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison <levim@php.net>: > > 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. > > I like that idea a lot tbh, but I do worry a lot about the lookup time > if we end up with a gigantic hashtable to hold all the symbols and the > implications it has. In most contexts we know (based on the syntax) > what we are looking for, however as it currently stands then it would > not be clear wether to look for the constant "trim" or the procedural > function "trim" in the example given, and if thats all the same, I can > see that many things not utilizing this could be slower for no good > reason (at least in my honest opinion). However I don't know if there > is something sneaky we can do here.
The symbols will probably kept in separate tables even after the change, with the order being determined by context. I don't worry about this performance hit, because callbacks are already so slow I don't think an extra hash lookup or two in the worst case will make this worse. And in some cases string callables have overhead at runtime because they have to search for "::", although I'm not up-to-date on where exactly we do this (it was looked into at one point).

Arvids Godjuks

7 years ago
пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen <kalle@php.net>:
> 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. >
Right click on `function::trim` - Find Usages. Basically allows to find all usages of a given function, including the callback usage.
> > 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); > > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
-- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius

Victor Bolshov

7 years ago
Yeah, that was part of the idea, the other being to make these callbacks semantically different from strings. Its just weird that a string is callable, isn't it? On Fri, Oct 26, 2018 at 6:03 PM Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
> пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen <kalle@php.net>: > > > 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. > > > > Right click on `function::trim` - Find Usages. Basically allows to find all > usages of a given function, including the callback usage. > > > > > 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); > > > > > > > > -- > > regards, > > > > Kalle Sommer Nielsen > > kalle@php.net > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > Arvīds Godjuks > > +371 26 851 664 <+371%2026%20851%20664> > arvids.godjuks@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius >
-- Best regards, Victor Bolshov

Victor Bolshov

7 years ago
I don't think it's quite the same, and although I can agree that short lambdas look better then normal in this context, I would still prefer function::trim On Fri, Oct 26, 2018 at 5:42 PM Larry Garfield <larry@garfieldtech.com> wrote:
> On Friday, October 26, 2018 7:29:46 AM CDT Crocodile wrote: > > Hi internals! > > > > I have this idea of improving the way to specify callbacks for good old > PHP > > functions. For instance, I have this piece of code: > > > > --------------- > > array_filter($names, 'trim') > > --------------- > > > > The callback function name is specified as a string, which makes it > > not-so-obvious, although this is definitely a PHP way. An alternative > would > > be to rewrite this using a lambda: > > > > --------------- > > array_filter($names, function($name) { return trim($name); }) > > --------------- > > > > This is way more wordy, and I bet most of us will go for the first > option. > > > > What if we had a more clear way of specifying those callbacks? I suggest > > the following: > > > > --------------- > > array_filter($names, function::trim) > > --------------- > > > > It is, I believe, more clear then a simple string, just a bit more wordy, > > and since "function" is a reserved word which never had anything to do > with > > "::", the lexer/parser could probably find a way to deal with this kind > of > > syntax (well, honestly, this part is totally unclear for me because I > only > > work with PHP from userland). > > > > Does anyone else find this could be a good addition? Or is it not worth > > considering? Or maybe I am missing some obvious pitfalls? > > > > Cheers, > > Victor > > 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)) > > --Larry Garfield
-- Best regards, Victor Bolshov

David Rodrigues

7 years ago
Em sex, 26 de out de 2018 às 09:30, Crocodile <crocodile2u@gmail.com> escreveu:
> Hi internals! > > I have this idea of improving the way to specify callbacks for good old PHP > functions. For instance, I have this piece of code: > > --------------- > array_filter($names, 'trim') > --------------- > > The callback function name is specified as a string, which makes it > not-so-obvious, although this is definitely a PHP way. An alternative would > be to rewrite this using a lambda: > > --------------- > array_filter($names, function($name) { return trim($name); }) > --------------- > > This is way more wordy, and I bet most of us will go for the first option. > > What if we had a more clear way of specifying those callbacks? I suggest > the following: > > --------------- > array_filter($names, function::trim) > --------------- >
And about methods? How it should works if I wants to call a method from a custom class? It should be function::CustomClass::someMethod?
> > It is, I believe, more clear then a simple string, just a bit more wordy, > and since "function" is a reserved word which never had anything to do with > "::", the lexer/parser could probably find a way to deal with this kind of > syntax (well, honestly, this part is totally unclear for me because I only > work with PHP from userland). > > Does anyone else find this could be a good addition? Or is it not worth > considering? Or maybe I am missing some obvious pitfalls? > > Cheers, > Victor > -- > Best regards, > Victor Bolshov >
-- David Rodrigues

Victor Bolshov

7 years ago
My proposal would not work for methods. function::CustomClass::someMethod - that doesn't look great at all, at least to me. On Fri, Oct 26, 2018 at 6:08 PM David Rodrigues <david.proweb@gmail.com> wrote:
> Em sex, 26 de out de 2018 às 09:30, Crocodile <crocodile2u@gmail.com> > escreveu: > > > Hi internals! > > > > I have this idea of improving the way to specify callbacks for good old > PHP > > functions. For instance, I have this piece of code: > > > > --------------- > > array_filter($names, 'trim') > > --------------- > > > > The callback function name is specified as a string, which makes it > > not-so-obvious, although this is definitely a PHP way. An alternative > would > > be to rewrite this using a lambda: > > > > --------------- > > array_filter($names, function($name) { return trim($name); }) > > --------------- > > > > This is way more wordy, and I bet most of us will go for the first > option. > > > > What if we had a more clear way of specifying those callbacks? I suggest > > the following: > > > > --------------- > > array_filter($names, function::trim) > > --------------- > > > > And about methods? How it should works if I wants to call a method from a > custom class? It should be function::CustomClass::someMethod? > > > > > > > It is, I believe, more clear then a simple string, just a bit more wordy, > > and since "function" is a reserved word which never had anything to do > with > > "::", the lexer/parser could probably find a way to deal with this kind > of > > syntax (well, honestly, this part is totally unclear for me because I > only > > work with PHP from userland). > > > > Does anyone else find this could be a good addition? Or is it not worth > > considering? Or maybe I am missing some obvious pitfalls? > > > > Cheers, > > Victor > > -- > > Best regards, > > Victor Bolshov > > > > > -- > David Rodrigues >
-- Best regards, Victor Bolshov

Victor Bolshov

7 years ago
Sorry for a bunch of replies that simply have lost a lot of context.. I'll try to summarize it all here:
> 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)) > > --Larry Garfield
I don't think it's quite the same, and although I can agree that short lambdas look better then normal in this context, I would still prefer function::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
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.
> Right click on `function::trim` - Find Usages. Basically allows to find
all
> usages of a given function, including the callback usage.
Yeah, that was part of the idea, the other being to make these callbacks semantically different from strings. Its just weird that a string is callable, isn't it?
> And about methods? How it should works if I wants to call a method from a > custom class? It should be function::CustomClass::someMethod?
My proposal would not work for methods. function::CustomClass::someMethod - that doesn't look great at all, at least to me. On Fri, Oct 26, 2018 at 10:01 PM Crocodile <crocodile2u@gmail.com> wrote:
> My proposal would not work for methods. function::CustomClass::someMethod > - that doesn't look great at all, at least to me. > > > On Fri, Oct 26, 2018 at 6:08 PM David Rodrigues <david.proweb@gmail.com> > wrote: > >> Em sex, 26 de out de 2018 às 09:30, Crocodile <crocodile2u@gmail.com> >> escreveu: >> >> > Hi internals! >> > >> > I have this idea of improving the way to specify callbacks for good old >> PHP >> > functions. For instance, I have this piece of code: >> > >> > --------------- >> > array_filter($names, 'trim') >> > --------------- >> > >> > The callback function name is specified as a string, which makes it >> > not-so-obvious, although this is definitely a PHP way. An alternative >> would >> > be to rewrite this using a lambda: >> > >> > --------------- >> > array_filter($names, function($name) { return trim($name); }) >> > --------------- >> > >> > This is way more wordy, and I bet most of us will go for the first >> option. >> > >> > What if we had a more clear way of specifying those callbacks? I suggest >> > the following: >> > >> > --------------- >> > array_filter($names, function::trim) >> > --------------- >> > >> >> And about methods? How it should works if I wants to call a method from a >> custom class? It should be function::CustomClass::someMethod? >> >> >> >> > >> > It is, I believe, more clear then a simple string, just a bit more >> wordy, >> > and since "function" is a reserved word which never had anything to do >> with >> > "::", the lexer/parser could probably find a way to deal with this kind >> of >> > syntax (well, honestly, this part is totally unclear for me because I >> only >> > work with PHP from userland). >> > >> > Does anyone else find this could be a good addition? Or is it not worth >> > considering? Or maybe I am missing some obvious pitfalls? >> > >> > Cheers, >> > Victor >> > -- >> > Best regards, >> > Victor Bolshov >> > >> >> >> -- >> David Rodrigues >> > -- > Best regards, > Victor Bolshov >
-- Best regards, Victor Bolshov