Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
Message-ID: <52613DCD.2010301@gmail.com>
Date: Fri, 18 Oct 2013 14:55:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <525C631E.1050008@gmail.com> <CAF+90c9z6Xx8GY8zPvg8x0b953oyxfBV=_5znWVX7OG4Rb7oaQ@mail.gmail.com> <526136F8.6050300@rotorised.com>
In-Reply-To: <526136F8.6050300@rotorised.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proposal to deprecate create_function()
From: rowan.collins@gmail.com (Rowan Collins)

On 18/10/2013 14:26, Ryan McCue wrote:
> I can say with confidence that if this gets in to PHP, we'll integrate
> BC support as above (although probably some function name like
> `_wp_anonymous_function_$i`), and the only real reason we still have
> this is 5.2 support.
>
> I suspect by the time 5.next rolls around, we'll be at least considering
> dropping 5.2, but that of course depends on usage. At the very least,
> the plugin ecosystem is starting to look towards dropping 5.2 support,
> which is where the big issue will be anyway, so that's nice.
>
> (FWIW, I always hated the create_function() calls in WordPress anyway.)

That's interesting to hear - I have no knowledge of the Wordpress 
community and decision-making apparatus, so wasn't sure what the 
reaction would be. While digging around for references, I did find this 
ticket about removing a lot of the create_functions from core: 
http://core.trac.wordpress.org/ticket/14424

The usages I did find in the core code were what inspired my idea for a 
wrapper that took a list of variables to "close over" (like a use() 
clause without the extra syntax) and used var_export() to inject them 
into the function body, as that is the pattern used in a few places.

The other interesting case I spotted was creating a function which 
always returned the same string (an SQL LIMIT clause), so that it could 
be registered as a filter callback. That could use an even simpler 
BC-wrapper, which wouldn't need any eval() at all in >=5.3 (as long as 
code was arranged such that older versions didn't try to compile it):

function lambda($return_value)
{
     return function() use($return_value) { return $return_value; };
}


A fallback definition for <=5.2 would have a single var_export:


function lambda($return_value)
{
     return create_function('', 'return ' . var_export($return_value, 
true) . ';');
}

-- 
Rowan Collins
[IMSoP]