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]