Introduce the abiltiy to use the first-call-callable syntax on non-static methods, statically

You are absolutely correct. I guess the solution would be to handle it differently in this case.

Creating a closure from a static method would be fine, as it creates a static closure, but when attempting to create a static closure from a non-static method, it would instead return a closure that errors if it isn't bound to an appropriate object. You'd most likely want to restrict this to public methods only, which would help with the security issues.

There's already a check there that throws an error, so we can already tell the difference there, but the tricky part will be in the returned closure. Perhaps something like "BindingClosure" that throws the static error when attempting to call it unbound, or better yet, a more descriptive error about it requiring binding.

Would that be feasible?

Hello all,

I've created a feature request issue on GitHub (here:
https://github.com/php/php-src/issues/10414), but I have been advised
that it's best to post here.

What I would like to introduce/suggest, is the ability to create a
closure from a method using the first-class-callable syntax (eg:
MyClass::aMethod(...)), for a non-static method, statically.

Currently, the following code causes an error.

class Test {
    public function test(): string { return 'test'; }
}

$closure = Test::test(...);

I understand why the error is thrown, but, and I'm unsure of the
specifics regarding this, I think we could delay the error until the
closure was called. The reason for this, is that closures can be bound,
so if you followed on from the code above, you could do the following:

$closure->bindTo(new Test);
$closure();

The above would bind the closure in $closure to the scope of an object,
which in this case, is the class that the method belongs to.

The best example I can think, for this, would be when filter a
collection of instances. If you were using a collection library, you
would currently have something like the following:

$collection->filter(function (Str $string) {
    return !$string->empty();
});

Whereas it would be much nicer to have the following:

$collection->filter(Str::empty(...));

In this situation, the collection library would be responsible for
binding the closure to the value it is iterating.

So you'd implement this yourself elsewhere?

class Str {
public function empty(): bool { ... }
}

I don't see in this example how this is any better than what is already currently possible:

class Str {
public static function empty(Str $s): bool { ... }
}

$collection->filter(Str::empty(...));

I have limited experience with PHPs source, and C in general, but my
understanding would be that if we were creating a closure, we would
skip the check for the static method. The code responsible for handling
the closure call would most require some additional functionality to
check if it was bound to a valid instance, returning an error if it
isn't, and then returning an error if it isn't bound at all and the
method isn't static.

The more I think about it, the more I think this may require a new type
of Closure, or at least a runtime applied interface, to help developers
determine whether a closure was created using first-class-callable
syntax.

This is, I think, the important part here, and would be a prerequisite. Right now there's no way (as far as I know) to differentiate a closure that is callable from one that would be callable if it were bound to an object. That's generally not a huge deal in practice as unbound closures are not often used, but what you're suggesting would make them much more likely. Also, a static closure cannot be bound, so you cannot just blindly bind whatever callable you're passed to $this, in your example. (Besides, blindly binding a closure to $this sounds like a great security hole.)

So for some variant of this to work, I think you'd first need to think through how to (easily and without dipping into reflection) determine if a closure object is bindable (static or not) and if it's already bound. Once that's figured out, then we can see what, if any, short-hand way to make a not-yet-bound closure makes sense. (Which could be FCC syntax or not, I don't know.)

--Larry Garfield

--

To unsubscribe, visit: https://www.php.net/unsub.php

---

Best Regards,
Ollie Read

FWIW, I think we can "throw out" any automatic binding, that just
complicates things.

In my mind, Test::Func(...) should be treated the same as ['Test',
'Func'] or 'Test::Func' until it is called and if some fancy framework
wants to do something special with the closure, it can do so. FWIW, I
didn't even know this syntax checked anything until today. I can think
of a number of cases where delaying the error to actual execution is
beneficial.

1. Just because the method/object doesn't exist, doesn't mean it won't
   exist by the time it is called -- this is PHP after all.
2. I can have a file with 100 million of these things without
   triggering any autoloading.
3. PHPStorm currently doesn't trigger this syntax as an error.

You are absolutely correct. I guess the solution would be to handle it
differently in this case.

Creating a closure from a static method would be fine, as it creates a
static closure, but when attempting to create a static closure from a
non-static method, it would instead return a closure that errors if it
isn't bound to an appropriate object. You'd most likely want to
restrict this to public methods only, which would help with the
security issues.

Then don't make it a non-static method? Using an object method as a static method has been bad practice for as long as I can remember and an error since sometime recently, I think, so let's not do that.

There's already a check there that throws an error, so we can already
tell the difference there, but the tricky part will be in the returned
closure. Perhaps something like "BindingClosure" that throws the static
error when attempting to call it unbound, or better yet, a more
descriptive error about it requiring binding.

Would that be feasible?

By the time the error is thrown is too late. It's a distinction that needs to be made before the bind. So you could do like:

if ($fn->needsBinding()) {
$fn = $fn->bindTo($o);
}

(Or something.)

That said, it sounds like you're talking about something different anyway that is probably unfeasible.

Also, please do not top post.

--Larry Garfield

$fnConstructor = Closure::fromClassConstructor(Zoq::class);
// signature of $fnConstructor is the same as function(Fot $fot): Zoq

Or for individual methods:

$fnMethod = Closure::fromClassMethod(Zoq::class, 'Pik');
// signature of $fnMethod is the same as function(Zoq $zoq, string $zebranky): Frungy

I don't think that actually helps. If you have the object already,

Neither of new functions I was suggesting have the object already.
Only the type.

If you do not have the object already, then we run back into the issue
I pointed out before where we need to differentiate a bindable from
needs-binding callable,

That's not what I suggesting.

Danack wrote:

$fnConstructor = Closure::fromClassConstructor(Zoq::class);
signature of $fnConstructor is the same as function(Fot $fot): Zoq

That doesn't need a binding at all.

Danack wrote:

$fnMethod = Closure::fromClassMethod(Zoq::class, 'Pik');
signature of $fnMethod is the same as function(Zoq $zoq, string $zebranky): Frungy

First parameter is the object to be operated on. You wouldn't need to
do any binding. magic would happen inside the function to take care
of that.

I think that's a prerequisite for adding any dedicated syntax
for "make a closure that doesn't work until it gets bound".

To be clear, I don't support anything like that. As I wrote:

Danack wrote:

That sounds like a complete non-starter. Adding something to the
language that produces a closure that can't be called would be an
instant new entry for PHPSadness.

cheers
Dan
Ack