Draft RFC callable types + callable type/function autoloading

  110216
May 20, 2020 13:00 Danack@basereality.com (Dan Ackroyd)
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
  110226
May 21, 2020 01:28 tysonandre775@hotmail.com (tyson andre)
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.

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 to `strlen()` or `Foo\strlen`).
  What were your plans for handling ambiguous calls?
  I was in favor of checking if either existed (current behavior) before autoloading `Foo\strlen`, then before autoloading `strlen`, 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
  110227
May 21, 2020 01:54 tysonandre775@hotmail.com (tyson andre)
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
  110230
May 21, 2020 09:09 php-lists@koalephant.com (Stephen Reay)
> On 20 May 2020, at 20:07, Dan Ackroyd <Danack@basereality.com> wrote: > > 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
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
  110281
May 26, 2020 17:08 txigreman@hotmail.com (=?iso-8859-1?Q?Iv=E1n_Arias?=)
> 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.
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 Ackroyd<mailto:Danack@basereality.com> Enviado: miércoles, 20 de mayo de 2020 15:01 Para: PHP internals<mailto: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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
  110797
July 1, 2020 09:55 Danack@basereality.com (Dan Ackroyd)
On Tue, 26 May 2020 at 18:08, Iván Arias <txigreman@hotmail.com> wrote:
> 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
  110808
July 1, 2020 19:40 larry@garfieldtech.com ("Larry Garfield")
On Wed, Jul 1, 2020, at 4:55 AM, Dan Ackroyd wrote:
> On Tue, 26 May 2020 at 18:08, Iván Arias <txigreman@hotmail.com> wrote: > > 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
  110813
July 2, 2020 10:26 Danack@basereality.com (Dan Ackroyd)
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. cheers Dan Ack
  110814
July 2, 2020 10:35 nikita.ppv@gmail.com (Nikita Popov)
On Thu, Jul 2, 2020 at 12:26 PM Dan Ackroyd <Danack@basereality.com> wrote:

> 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