# Idea for better function callbacks (another syntactic sugar) - Thread: https://externals.io/message/103390 - Original archive: https://news-web.php.net/php.internals/103390 - Started by Crocodile on 2018-10-26T12:29:46+00:00 - Messages: 14 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #103390 — Crocodile — 2018-10-26T12:29:46+00:00 URL: https://externals.io/message/103390#103390 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 --- ## #103391 — Larry Garfield — 2018-10-26T15:42:47+00:00 URL: https://externals.io/message/103390#103391 · In reply to: #103390 > 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 --- ## #103392 — Kalle Sommer Nielsen — 2018-10-26T15:56:44+00:00 URL: https://externals.io/message/103390#103392 · In reply to: #103391 Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield : > 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 --- ## #103393 — Levi Morrison — 2018-10-26T16:02:49+00:00 URL: https://externals.io/message/103390#103393 · In reply to: #103392 > > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield : > > […] > > 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. --- ## #103394 — Arvids Godjuks — 2018-10-26T16:03:03+00:00 URL: https://externals.io/message/103390#103394 · In reply to: #103392 пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen : > Den fre. 26. okt. 2018 kl. 17.43 skrev Larry Garfield < > larry@garfieldtech.com>: > > […] > some > > […] > > 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 > > -- > > > > -- Arvīds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius --- ## #103395 — David Rodrigues — 2018-10-26T16:08:18+00:00 URL: https://externals.io/message/103390#103395 · In reply to: #103390 Em sex, 26 de out de 2018 às 09:30, Crocodile 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 --- ## #103396 — Benjamin Morel — 2018-10-26T17:07:58+00:00 URL: https://externals.io/message/103390#103396 · In reply to: #103393 > > 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? --- ## #103397 — Crocodile — 2018-10-26T19:56:10+00:00 URL: https://externals.io/message/103390#103397 · In reply to: #103391 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 wrote: > > > […] > PHP > > […] > would > > […] > option. > > […] > with > > […] > of > > […] > only > > […] > > 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 --- ## #103398 — Crocodile — 2018-10-26T19:58:26+00:00 URL: https://externals.io/message/103390#103398 · In reply to: #103393 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 9:57 AM Kalle Sommer Nielsen > wrote: > > […] > larry@garfieldtech.com>: > > […] > at some > > […] > > 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. > > -- > > > > -- Best regards, Victor Bolshov --- ## #103399 — Crocodile — 2018-10-26T20:00:07+00:00 URL: https://externals.io/message/103390#103399 · In reply to: #103394 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 wrote: > пт, 26 окт. 2018 г. в 18:57, Kalle Sommer Nielsen : > > > […] > at > > […] > > Right click on `function::trim` - Find Usages. Basically allows to find all > usages of a given function, including the callback usage. > > > […] > > -- > 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 --- ## #103400 — Crocodile — 2018-10-26T20:01:29+00:00 URL: https://externals.io/message/103390#103400 · In reply to: #103395 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 wrote: > Em sex, 26 de out de 2018 às 09:30, Crocodile > escreveu: > > > […] > PHP > > […] > would > > […] > option. > > […] > > And about methods? How it should works if I wants to call a method from a > custom class? It should be function::CustomClass::someMethod? > > > > > […] > with > > […] > of > > […] > only > > […] > > > -- > David Rodrigues > -- Best regards, Victor Bolshov --- ## #103401 — Crocodile — 2018-10-26T20:06:20+00:00 URL: https://externals.io/message/103390#103401 · In reply to: #103400 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. > 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 > wrote: > > > […] > -- > Best regards, > Victor Bolshov > -- Best regards, Victor Bolshov --- ## #103402 — Kalle Sommer Nielsen — 2018-10-26T21:09:41+00:00 URL: https://externals.io/message/103390#103402 · In reply to: #103393 Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison : > 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 --- ## #103407 — Levi Morrison — 2018-10-28T02:54:04+00:00 URL: https://externals.io/message/103390#103407 · In reply to: #103402 > > Den fre. 26. okt. 2018 kl. 18.03 skrev Levi Morrison : > > […] > > 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).