Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88656
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <8D.64.31315.E67F0165@pb1.pair.com>
To: internals@lists.php.net
References: <CA+kxMuSFP=vooMzCYMapTsis6RGBVd-T4YM9z3YuxgF3Rcj6EQ@mail.gmail.com>
Date: Sun, 4 Oct 2015 10:54:51 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Firefox/38.0 SeaMonkey/2.35
MIME-Version: 1.0
In-Reply-To: <CA+kxMuSFP=vooMzCYMapTsis6RGBVd-T4YM9z3YuxgF3Rcj6EQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] [DISCUSSION]: Closure from callable
From: ajf@ajf.me (Andrea Faulds)

Hi Dan,

Dan Ackroyd wrote:
>
> https://wiki.php.net/rfc/closurefromcallable
>

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.

-- 
Andrea Faulds
http://ajf.me/