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
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
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
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.
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?
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 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.--
--
Best regards,
Victor Bolshov
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
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).
пт, 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--
--
Arvīds Godjuks
+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius
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--
--
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
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:
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,
VictorI 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
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,
VictorBest regards,
Victor Bolshov
--
David Rodrigues
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,
VictorBest regards,
Victor Bolshov--
David Rodrigues
--
Best regards,
Victor Bolshov
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 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,
VictorBest regards,
Victor Bolshov--
David Rodrigues--
Best regards,
Victor Bolshov
--
Best regards,
Victor Bolshov