[RFC] Closure::call and Function Referencing as Closures

Is the advantage of Closure#call() only performance? Because I don't
see other advantages otherwise, and I don't think the performance impact is
relevant.

There is a performance advantage which I’m going to test at some point,
but that’s not why I propose adding it. It is to simplify binding closures.
It’s not an uncommon operation to want to bind at call-time in other
languages, and it can be useful.

The fact that I'm arguing about is "yet another method to maintain" for an
API that can simply live in userland (and is easier to
maintain/upgrade/etc)...
Unless there's a huge overhead, I don't see a problem with creating new
closures: I do a lot of performance-sensitive stuff with Closure::bind()
and I don't see how this API could help me.

As for the function referencing RFC, I like it, but it is an annoying
syntax that seems to have been built just to accomodate the parser, and
that can be worked around in userland with overhead and more typing:

$functionReference = function ($param) { return functionName($param); };

That doesn’t work properly for class methods, both instance and static. It
doesn’t even work properly for normal functions, as you’re stripping away
parameter information.

Why do you actually need parameter information here?
Starting from PHP 5.6, dynamic parameters can be passed on via variadics
anyway. By-ref and by-val is also no big deal as well.

This kind of call can be recognized by static analyzers, and can be
refactored by IDEs.

A syntax that I'd like, and which is IMO BC compatible would
be::function:

array_map(count::function, [[1, 2], [3, 4]]);

This is also very similar and similarly readable to what we have right
now with PHP 5.5 through the ::class meta-constant.
There's also no way to use function as a constant anywhere, so it
should be safe to use that right now.

That syntax isn’t doable in the parser and isn't backwards-compatible
anyway. Classes and functions share the same namespace, so what do you do
when I have a class called FooBar and a function called FooBar?

FooBar::methodName::function vs FooBar::function - clear and simple IMO.

Consider http://3v4l.org/SY6vD, http://3v4l.org/YuMZ2 and
http://3v4l.org/9ZRFN

How about if I have a class with a constant named function?

Not allowed by the language

How do you propose to implement this pseudo-class system where functions
act like classes in only one case, when fetching this fake class constant?

I'm not: ::function is not a constant, it would be recognized by the
parser directly.

How do you deal with the fact that constants cannot (with very good
reason) be objects?

Not sure what you mean with this..

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Hi!

It doesn’t collide, there is no syntactical ambiguity at an engine
level, at least. It does unfortunately look similar, however. The

That's the collision. It looks exactly the same, but does entirely
different thing. This is not good.

choice of syntax is largely for a lack of better alternatives. It
also matches what C and C++ do. I had wanted to do something like

It doesn't match what C and C++ do - it does a completely different
thing from what C and C++ do. It's not an address and it's not a reference.

The hope is that it’d be more obvious a function is being referenced
without needing to know the signature of the function to which the

I don't understand how for writing "strlen" you need to know its signature.

callable is being passed. I suppose it also means you could type hint
for Closure instead of callable to guarantee you get an object you
can use the Closure methods on.

Didn't we add "callable" exactly for identifying callables? So now
callable is not enough and we need also typing by Closure? But wait,
callable is still supported for calling, so what you want to do with
Closure? Right now it has two methods - for binding - and both are not
guaranteed to work at all - as you just said, it would fail to work on
any internal function and on most non-internal functions too, since they
have no idea what to do when bound. So you get an object that actually
guarantees nothing at all.

PHP’s functions aren’t first-class, we just have a way to reference
them with strings. What we do is similar to what C does with function

In what meaning they are not first-class that your change is making them
first-class?

pointers. An advantage of being able to get normal functions and
methods as closures is it means that anything we add to the Closure
class can be used on them. For example, if we added built-in partial

But it can not. E.g. you can not bind such things. They can not have
environments. They only thing you can do with them is call them - but
you can do it right now!

application (something I’d sure like to see, it’s just difficult to
implement), you’d be able to use it on any existing userland or

You can do partial application to any callable just now by generating an
anon function that applies it via call_use_function. The only thing
introducing Closure there would change is how the method being called is
named.

extension function. If we added built-in currying, a related feature,
you’d also be able to use it. The syntax means PHP no longer has two
classes of functions, essentially.

We don't have two classes of functions right now. If you go to engine
level, we have more than that, if you stay on PHP level, you just have
callable, which is not really a function but rather a way to address a
function.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

"->call()" would facilitate the following syntax, which I'd argue has greater semantic meaning than the call_user_func() variant:

$f->bar->call()->call();

At the risk of stating the obvious, can’t you just use $f->bar->__invoke()?

Andrea Faulds
http://ajf.me/

Hi Andrea,

Could you measure the performance impact of function referencing.

<?php
$func = "strlen";
for ($i = 0; $i < 10000; $i++) {
$func("hello");
}
?>

vs

<?php
$func = &strlen;
for ($i = 0; $i < 10000; $i++) {
$func("hello");
}
?>

On my machine:

andreas-air:php-src ajf$ time sapi/cli/php ../funcref_a.php

real        0m0.043s
user        0m0.022s
sys 0m0.008s

andreas-air:php-src ajf$ time sapi/cli/php ../funcref_b.php

real        0m0.023s
user        0m0.015s
sys 0m0.006s

I think the reason that function references are faster here is that it
only has to do the hash table lookup once. If you tried to create a
reference on each iteration and compared that to just using the string,
then the string would be faster, as no memory needs to be allocated and
deallocated for the closure.

I don't like the "&" syntax a lot, but I understand that it's a
compromise between readability and implementation complication.

Right. Myself, I’d prefer to just merge PHP’s namespaces and have $foo =
func_name; work, but that wouldn’t work well and would break a lot of
things.

may be:

$a = function strlen;

or

$a = function(stren);

but these are not excellent as well :(

The patch probably misses support for "&self::foo", "&parent::foo",
"&static::foo”.

Good catch, I’ll try and get that implemented. Actually, I wonder if
having &self::foo be bound to the object using it would be a good idea.
While I resisted for &$foo::bar (I don’t support that syntax anyway), there
might be some merit in it after all. If it would bind for you, you could
always remove the binding or change it if it would be a problem.

It also may be improved using run_time cache (this is not important now).

That’s something I wanted to do (might solve the performance problems with
using & on each iteration), but I’m not sure quite what the right way to
implement that is. In particular, what kind of cache (some sort of hash
map?), how to index it (function name? fully-qualified function name?) and
where to put it. I suppose I could just add a zval pointer to zend_function
itself, but that would add eight bytes to every single function, which
would add up.

Actually, on a related note: Currently & creates a new closure on each
use, and in PHP closures are compared by identity, not by their value.
Perhaps we should change that so it checks for the same scope, this_ptr and
implementation? Having &strlen === &strlen would probably be a good thing,
it’s the more intuitive thing at least. Comparing the this_ptr of the two
would be easy, however I have no idea whether you could compare the two
zend_functions and have it work properly. You can’t just do an == in the C
code, as closures embed and modify the zend_function.

I may implement this part if the RFC will be accepted.
Actually, most of the code may be just copy-pasted from
ZEND_INIT_STATIC_METHOD_CALL.

Thanks. Dmitry.

--
Andrea Faulds
http://ajf.me/

Hi!

Sorry for the slow response, I’ve been on holiday.

The RFC goes a long way to fixing this, but one important place it
misses is with function references to private and protected methods.
The crux of the issue is that allowing an unbound closure to escape can
lead to very unexpected and unwanted results, as opposed to forcing the
closure to be bound to a particular variable. Consider:

<?php
class C {
private function priv() { /* ... */ }
public function pub() {
// ... do stuff ...
// Return a closure for the caller to call priv at a later date:
return &self::priv;
}
}

While this example is somewhat contrived, I've certainly wanted to do
something similar before. The intent of this code is for the closure
returned by "pub" to only ever be called on what was $this inside "pub"
-- but not only can you change that with bind() on the closure, "pub"
itself cannot even pre-bind it to the intended $this. Or maybe it
technically could by calling bind() on the result of &self::priv before
returning it, but that's very cumbersome for what is the common case
for what you want to do with "function pointer" to a non-static method.

Unfortunately, yes, such closures are not pre-bound. However invoking
it when it’s unbound will produce the same error as calling any method
statically (E_STRICT or E_ERROR), so the issue can be noticed and fixed
easily. It’s possible to bind with Closure::bind(&Foo::bar, ‘Foo’); or
something like that. I could make it pre-bind, but I’m unwilling to as
:: never binds when calling, so it shouldn’t when referencing for
consistency.

You're rather pre-supposing the proposed syntax there, and letting it lead the semantics rather than vice versa. The point is it would be useful to allow creation of a pre-bound closure based on an existing method, so it would be good if the syntax allowed that possibility.

Getting a static reference to a non-static method and then binding it feels a bit like JS, which has a completely different notion of what a method is. And it's noteworthy that pre-bound methods are one of the things being added in ECMAScript.next

Using the ‘Closure’ class is unfortunate, but I don’t really want to
make unnecessary new Function/Method/etc. classes given they’d all
share the same implementation anyway.

I'm not so sure they'd be identical - a static method or plain function would presumably error if you tried to bind it, for instance. For whatever reason, there's a tendency for internal classes to take on multiple responsibilities which a userland framework would separate out - SimpleXML is the extreme example. If we were designing a fully OO language with first-class functions (which, clearly, we're not), a hierarchy of classes to represent different "states" of these immutable objects would be the obvious choice. The alternative (which SimpleXML is also missing, incidentally) is to have one class, but include methods for interrogating its type - e.g. isBound(), isBindable(), etc

--
Rowan Collins
[IMSoP]

Hi!

Sorry for the slow response, I’ve been on holiday.

No problem!

The RFC goes a long way to fixing this, but one important place it misses is with function references to private and protected methods. The crux of the issue is that allowing an unbound closure to escape can lead to very unexpected and unwanted results, as opposed to forcing the closure to be bound to a particular variable. Consider:

<?php
class C {
private function priv() { /* ... */ }
public function pub() {
// ... do stuff ...
// Return a closure for the caller to call priv at a later date:
return &self::priv;
}
}

While this example is somewhat contrived, I've certainly wanted to do something similar before. The intent of this code is for the closure returned by "pub" to only ever be called on what was $this inside "pub" -- but not only can you change that with bind() on the closure, "pub" itself cannot even pre-bind it to the intended $this. Or maybe it technically could by calling bind() on the result of &self::priv before returning it, but that's very cumbersome for what is the common case for what you want to do with "function pointer" to a non-static method.

Unfortunately, yes, such closures are not pre-bound. However invoking it when it’s unbound will produce the same error as calling any method statically (E_STRICT or E_ERROR), so the issue can be noticed and fixed easily. It’s possible to bind with Closure::bind(&Foo::bar, ‘Foo’); or something like that. I could make it pre-bind, but I’m unwilling to as :: never binds when calling, so it shouldn’t when referencing for consistency.

My point is not that you might forget to bind() the Closure, agree that it's taken care of just fine as-is. My point is that there's no way for pub() to express that it only ever expects the closure returned to be bound to the object on which you called pub(). Not only is the caller free to bind it to some other variable, but the bug might not be obvious at all since there's nothing constraining the call to bind() to happen nearby to the code in pub() where the intent that it only be bound to that object is clear. Everything here is conventional, when IMO it should be contractual, most especially since an unbound Closure isn't even meaningful to use (except to bind it before using it).

You can't do any of those things to the "real" function, so it's unclear if it makes sense to be able to do it to the callable reference.

Well, closures are immutable, to be fair. bind and bindTo actually produce new functions, and they don’t even work on static closures anyway. You’re not really doing these things to the “real” function.

Ah, whoops -- it's apparently an HHVM-ism that you can add properties to Closures :) http://3v4l.org/adEgO The rest of the point I was making here basically boils down to being able to bind/re-bind them, which is the same as the one I'm trying to make above, so I won't belabor it.

Josh Watzman

Side note, but that’s because __invoke on Closure doesn’t actually exist. It’s a method that is created by trying to access it and ceases to exist once called. Freaky, right?

Do you have an example where this feature could be very helpful? This exact feature?

What, __invoke existing? I have no idea, I assume it exists for completeness.

--
Andrea Faulds
http://ajf.me/