Hi internals,
A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callables
The reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.
What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.
So here are two draft RFCs:
Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.md
Function + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md
I'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.
I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.
cheers
Dan
Ack
Hi Dan Ackroyd,
Function + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md
I'd be happy to see function autoloading support in php overall.
It'd help in avoiding loading unnecessary polyfills, or in large codebases with many global functions that are only occasionally used.
Autoloading functions involves a lot of tradeoffs due to design choices in PHP.
I've seen a lot of different opinions - It might be worth setting up a straw poll for whether people would be interested in the change, unless you expect the php 8 implementation to be easy.
(though straw polls have much lower response rates than RFCs)
- Functions can be added to a namespace after they get added to the global scope.
- A lot of namespaced php code refers to functions ambiguously
(namespace Foo; echo strlen($x);
can either refer tostrlen()
orFoo\strlen
).
What were your plans for handling ambiguous calls?
I was in favor of checking if either existed (current behavior) before autoloadingFoo\strlen
, then before autoloadingstrlen
, to keep performance acceptable.
Others preferred various alternate approaches to autoloading.
I don't think there was ever a straw poll to measure how common other opinions were,
or if people would accept a given approach despite having a preference for something else.
The alternatives I can imagine/remember from previous RFC discussions, none of which I hold (https://wiki.php.net/rfc/use_global_elements#deprecate_the_fallback_to_the_root_namespace_instead and below had somewhat related discussion as an attempt to reduce ambiguity):
- The exact way to deal with ambiguity when autoloading, e.g. "autoload Foo\strlen() every single time
strlen()
is called" (I object because that would harm performance significantly) - You should make calling static methods easier (doesn't help with a lot of internal functionality like
strlen()
or polyfills for PECL functions are global functions)
Other thoughts:
- Maybe it would be useful/practical to initially just support autoloading functions when they're passed to function_exists($name, autoload: true) or autoload_function($name).
I don't remember if that approach was suggested before.
Then again, I'd personally want something more powerful than that due to the inconvenience, and I imagine most people would.
Thanks,
- Tyson
Hi Dan Ackroyd,
I'd be happy to see function autoloading support in php overall.
It'd help in avoiding loading unnecessary polyfills,
or in large codebases with many global functions that are only occasionally used.
I forgot, but I'd also started the thread https://externals.io/message/107967
("Autoloading functions/consts without a performance impact") 5 months ago,
and got sidetracked looking into ways to reduce ambiguity in calls to functions.
It might have been a better idea for me to start a straw poll instead of that,
but I didn't know how representative initial feedback was,
and I'm no longer working on autoloading.
Some of the messages might be relevant for the "Discussions" section of an RFC.
Thanks,
- Tyson
Hi internals,
A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callablesThe reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.So here are two draft RFCs:
Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.mdFunction + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.mdI'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.cheers
Dan
Ack--
Hi Dan,
From a userland perspective I like both of these, a lot.
I have a question though, and i wasn’t sure if you’d rather discuss particular points here on in a GH issue.
Would the changes to spl_autoload_* impact on the built in autoload implementation, spl_autoload?
Cheers
Stephen
Hi internals,
A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callablesThe reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.So here are two draft RFCs:
Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.mdFunction + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.mdI'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.
Hi!
Just a Little question. I see this other document in the same repo:
https://github.com/Danack/FunctionTypes/blob/master/3_referencing_functions_and_callables.md
Are you planning to also raise it?
As userland developer it really bothers me to type function and method names in strings.
Thanks in advance!
Un saludo,
Iván Arias.
De: Dan Ackroydmailto:Danack@basereality.com
Enviado: miércoles, 20 de mayo de 2020 15:01
Para: PHP internalsmailto:internals@lists.php.net
Asunto: [PHP-DEV] Draft RFC callable types + callable type/function autoloading
Hi internals,
A while ago, I spent some time thinking about callables, and how they
are not very consistent, which makes people sad:
https://wiki.php.net/rfc/consistent_callables
The reason I didn't pursue that RFC is that although tidying up PHP
core to be more consistent would be nice, it would be a large amount
of work, that wouldn't dramatically improve the developer experience
when programming in PHP. In fact it would mostly just break otherwise
working code.
What would be better would be an RFC to make callables be more useful,
specifically by allowing you to define the parameter and return types
for them. Making it possible to autoload those types would be
required, and function autoloading is also a feature that has been
desired for a while.
So here are two draft RFCs:
Callable types
https://github.com/Danack/FunctionTypes/blob/master/1_callable_type_rfc.md
Function + callable type autoloading
https://github.com/Danack/FunctionTypes/blob/master/2_autoloading_part_2.md
I'll leave them on github for the moment, as it is easier to do PRs
and track issues there but I wanted to gather initial feedback before
getting closer to the RFC cutoff date.
I'll move them to the wiki and formally submit them for discussion
when the implementation is closer to being done.
cheers
Dan
Ack
Just a Little question. I see this other document in the same repo:
https://github.com/Danack/FunctionTypes/blob/master/3_referencing_functions_and_callables.md
Are you planning to also raise it?
Yes, but for PHP 8.1.
Although I think it's an important problem to solve, I don't actually
like it as a solution, for aesthetic reasons.
I'm planning to draft it as an RFC right after the 8.0 RFCs close,
which will give people a year to come up with a better solution.
cheers
Dan
Ack
Just a Little question. I see this other document in the same repo:
https://github.com/Danack/FunctionTypes/blob/master/3_referencing_functions_and_callables.md
Are you planning to also raise it?
Yes, but for PHP 8.1.
Although I think it's an important problem to solve, I don't actually
like it as a solution, for aesthetic reasons.I'm planning to draft it as an RFC right after the 8.0 RFCs close,
which will give people a year to come up with a better solution.cheers
Dan
Ack
On a related tangent, which someone else suggested was relevant here:
Levi Morrison wrote another RFC a while ago on partial function application:
https://wiki.php.net/rfc/partial_function_application
He hasn't had bandwidth to work on it, though. I have taken a stab at it, and mostly handed it over to Ilija Tovilo who has pushed it further along. It's not going to be ready for 8.0 by a long shot, but we're hoping to have it ready for 8.1. (Exact details to depend on the implementation, WIP.)
Although it's not the main goal, it would also offer a way to do effectively the same thing as the direct callable reference RFC:
https://wiki.php.net/rfc/partial_function_application#use_as_an_identifier
It's not an ideal substitute, but it's close to one and wouldn't require a separate syntax.
I mention it here mostly for transparency and to make sure we don't end up with multiple competing RFCs that duplicate functionality needlessly.
--Larry Garfield
it would also offer a way to do effectively the same thing
One use-case that would need to be covered for that would be for
callables where you don't know how many parameters there would be in
the callable.
duplicate functionality needlessly.
Good chance it might still be nice. Not only is the syntax a little
bit nicer imo:
// For some class
class Foo {
public static function quux() {
echo "I am quux";
}
}
// Partial version
Foo::class, 'quux';
// Dedicated version
$(Foo, quux);
As I find it easier to read, but also avoiding using strings to
reference functions/classes is probably less ambiguous for both humans
and computers.
cheers
Dan
Ack
On Wed, 1 Jul 2020 at 20:40, Larry Garfield larry@garfieldtech.com
wrote:it would also offer a way to do effectively the same thing
One use-case that would need to be covered for that would be for
callables where you don't know how many parameters there would be in
the callable.duplicate functionality needlessly.
Good chance it might still be nice. Not only is the syntax a little
bit nicer imo:// For some class
class Foo {
public static function quux() {
echo "I am quux";
}
}// Partial version
Foo::class, 'quux';// Dedicated version
$(Foo, quux);As I find it easier to read, but also avoiding using strings to
reference functions/classes is probably less ambiguous for both humans
and computers.
The partial function application version would be Foo::quux(?). That is,
looks just like a normal call, but with placeholders. Your version would of
course also work, but I'm not sure why someone would want to write it in
that particular way :)
Regards,
Nikita