Everything

php

[RFC] Support for <func>::function syntax

php.internals

Unnamed Person

5 years ago

Hello internals,

Looking for feedback on the idea of supporting `::function` syntax (or
`::fn`) for consistency with existing `::class` syntax:

$arr = ['apple'];
print_r(array_map(strtoupper::function, $arr));

(Apologies if this has already been discussed. Hard to search for
colon-colon-function.)

Benefits in my view are readability and potential use in static analysis.
Downsides (as implemented in proof-of-concept) are that it can be
needlessly littered in a lot of places, and that it breaks class consts
named `function`. I'd vote against it in its current state, but if people
like the general idea maybe the drawbacks can be addressed with a better
implementation.

Examples:
https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304b

Proof-of-concept:
https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patch

Adam

Larry Garfield

5 years ago

On Sat, Nov 7, 2020, at 5:41 PM, as@php.net wrote:

> Hello internals,
>
> Looking for feedback on the idea of supporting `::function` syntax (or
> `::fn`) for consistency with existing `::class` syntax:
>
>     $arr = ['apple'];
>     print_r(array_map(strtoupper::function, $arr));
>
> (Apologies if this has already been discussed. Hard to search for
> colon-colon-function.)
>
> Benefits in my view are readability and potential use in static analysis.
> Downsides (as implemented in proof-of-concept) are that it can be
> needlessly littered in a lot of places, and that it breaks class consts
> named `function`. I'd vote against it in its current state, but if people
> like the general idea maybe the drawbacks can be addressed with a better
> implementation.
>
> Examples:
> https://gist.github.com/adsr/2c0b9243986418af3cecf8046657304b
>
> Proof-of-concept:
> https://github.com/adsr/php-src/commit/07bb24243022ccef5823f6977d231f3535a48a07.patch
>
> Adam

There was some discussion earlier this year, although if memory serves it was in a thread whose name would not be helpful for searching.  Sorry, can't help there. :-/  (Maybe it was in the threads talking about ::class notation on objects?  Just a guess.)

Working strictly from memory:

* There was a lot of support in concept, but not universal.
* There was a lot of concern that ::function was just too damned long to type, so plenty of bikeshedding about shorter names.
* There's another RFC proposed that is currently stalled due to lack of time to add partial function application, which would kinda allow something similar-ish through a back door: https://wiki.php.net/rfc/partial_function_application .  That said, I don't think they would conflict so I'd be fine with both happening.

+1 from me in concept.

--Larry Garfield

Rowan Collins

5 years ago

On 08/11/2020 02:12, Larry Garfield wrote:

> There was some discussion earlier this year, although if memory serves it was in a thread whose name would not be helpful for searching.

Here it is: https://externals.io/message/108459

Some of the key points (not an exhaustive summary):

- Looking up a function's fully-qualified name would need to check at
run-time for the function's existence, since there are two possibilities
for any name that's not already fully-qualified ('foo' and
'current\namespace\foo'). This is different from ::class which (in most
cases) resolves the expression to a name at compile-time based on
current imports, and can resolve to a completely non-existent name.
There are cases where it resolves at run-time [see
https://wiki.php.net/rfc/class_name_literal_on_object] but none have the
case of "valid name but no such class defined", which would need to be
handled for functions.

- There was some discussion about the usefulness of returning the name,
or a callable object, or some way of providing both. Suggestions
included adding two new syntaxes, ::function and ::closure; simplifying
the creation of a callable object from a string; or returning an object
from which the name could be retrieved.

- Should (and could) the new syntax work with methods as well, e.g.
Foo::bar::function and $foo->bar::function. If foo::function returns a
string, these would logically need to return
['Fully\Qualified\Name\Of\Foo', 'bar'] and [$foo, 'bar'] respectively;
if it (or a variant of it) returns a Closure, it would be the
(optimized) equivalent of passing those to Closure::fromCallable.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]

Michael Voříšek - ČVUT FEL

5 years ago

Hi,

what about resolving directly to Closure?

strtoupper::function === \Closure::fromCallable('strtoupper').

$this->method::function === \Closure::fromCallable([$this, 'method']).

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

On 8 Nov 2020 00:41, as@php.net wrote:

Marco Pivetta

5 years ago

Hey Michael,
<http://ocramius.github.com/>


On Sun, Nov 8, 2020 at 9:38 AM Michael Voříšek - ČVUT FEL <
vorismi3@fel.cvut.cz> wrote:

> Hi,
>
> what about resolving directly to Closure?
>
> strtoupper::function === \Closure::fromCallable('strtoupper').
>
> $this->method::function === \Closure::fromCallable([$this, 'method']).
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>

From a tooling point of view, it would be super-interesting to get a FQN of
the function, instead of a closure (which is just `\Closure`).

In this snippet, I'd expect the output to be `foo\bar\baz\taz`:

```php
<?php

use function foo\bar\baz;

echo baz\taz::function;
```

Not sure if `string` is enough, but it worked really well for `::class`,
for which tools like psalm now have a dedicated `class-string` type :-)

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/