[RFC] [DISCUSSION]: Closure from callable

On 29/09/15 16:23, Dan Ackroyd wrote:

+1, I'm not sure it belongs into ext/reflection, though?

On Tue, Sep 29, 2015 at 8:23 AM, Dan Ackroyd <danack@basereality.com> wrote:

On Tue, Sep 29, 2015 at 8:23 AM, Dan Ackroyd <danack@basereality.com> wrote:

I fixed a formatting error in https://wiki.php.net/rfc/closurefromcallable#other_languages Overall it looks good. I have a small quibble with:

But that wouldn't make me vote no. I think it's valuable to have both (just not with Hack's names… those are awful).

Hi Dan, Dan Ackroyd wrote:

I've wanted something like this for a long time. All that being said, though, I'm not sure a function is the way to do it. In C I can just use the name of a function to get a function pointer, couldn't we do this in PHP somehow? That is, `array_map(strlen, ["foo", "foobar", "elePHPant"]);` rather than `array_map(closure('strlen'), ...)`. I realise this would be a bit difficult to do, but I think it's a nicer approach. Thanks.

On Tue, Sep 29, 2015 at 10:23 AM, Dan Ackroyd <danack@basereality.com> wrote:

Yes, but with one question: should it be named "reflection_closure"? (I don't like that, but:) the user-land rules [1] say it will begin with the extension name, and the coding standards [2] say it will if it's part of a parent set. Maybe put it in core instead of reflection extension. Or, since ext/reflection doesn't have any functions, we can bypass it. [1]: http://php.net/manual/en/userlandnaming.rules.php [2]: https://github.com/php/php-src/blob/master/CODING_STANDARDS#L110

Hi Dan, Dan Ackroyd wrote:

Here's some further thoughts on this RFC. I don't like that it's a function. Closure is a class, classes can have static and instance methods, and closure() looks like something that should be a method on Closure. In fact, it creates a closure, which a constructor would usually do. If we want to make it avoid duplication, okay, then it could be a static method. But I'm unconvinced it should be a function. Constructors go in their classes, we don't leave them lying around as global functions. That's messy and inconsistent. You say that it being a function would mean we could make it a language construct to improve performance. But making it a language construct means making Closure a reserved word, and probably break things, right? We don't need to use a language construct for performance, though. Zend Engine III lets us inline certain commonly-used functions (strlen and is_int, for example). This requires that function references be absolute with no ambiguity, which means prefixed with a backslash or being used in non-namespaced code... but in practice few people type \ before root namespace functions. Thing is, this ambiguity doesn't exist for classes. Any usage of, say, \Closure::from (if we were to call it that) would be inlineable, unless the programmer uses variable variables. So, I don't buy that we should use a function for potential future performance with a language construct, since we can do inlining with no breakage *right now* if we use a static method. If we *were* to make it a language construct, we should do it properly and use proper syntax. No closure("foo") or closure(array("SomeClass", "methodName")), instead closure(foo) or closure(SomeClass::methodName). And in that case, we'd probably use the existing reserved word for this: callable. By the way, as proposed, closure() has a performance penalty. You're calling a function to convert a callable into a closure, but that's almost always unnecessary. You could simply use the callable directly. closure(), as proposed, could also be done quite simply in userland, and even optimised. Why should it be added to PHP core? So, I think this proposal needs considerable work. Thanks.

On 29.09.2015 16:23, Dan Ackroyd wrote:

Your first example on the page is a little weird to me. You claim that one currently needs to have the callback method public, although you can easily work around that. Instead of doing this, as in your example: return [$this, 'genericValidation'] you could just do this: return function ($data) { return $this->genericValidation($data); } and keep the actual callback method private/protected.

As mentioned already by Andrea: why not just a named constructor on the closure class, like `Closure::fromCallable(callable $callable)`? Much simpler, easier to find, etc etc... On Sep 29, 2015 11:23, "Dan Ackroyd" <danack@basereality.com> wrote: