On 18/10/2013 13:39, Ferenc Kovacs wrote:
I've only skimmed through the thread, but did somebody already proposed
changing the return value of create_function to return a closure instead of
deprecating it?
I mentioned it briefly in my initial post, but felt that unless BC was 100%, it wasn't worth it, as you couldn't guarantee which of the current behaviour people were relying on.
People can always write a version in PHP which is good enough for their particular requirements.
If we really we want 100% compatibility, we could even add a __toString to
the Closure object with an internal function name (similar was proposed by
Joe for anonymous functions and I listed it as a con, because not matching
the current behaviors of Closures) through which it can be called as a
string while throwing a STRICT/DEPRECATED error so people can move away
from manipulating the return value as a string, and we can remove that
behavior later on.
That's an interesting idea, although I'm not sure about adding a feature and immediately deprecating it. It seems like if closures had a __toString, people would start to use it, so we would have to assume that the feature was there to stay.
Another thought I had was to implement a safer version of create_function() under a different name, and provide a PHP-level implementation which ran under old versions for forwards-compatibility. You could, for instance, take an associative array of variables to close over, which would be equivalent to the use() statement if implementing on top of closures, and use var_export() to interpolate into a legacy create_function() implementation:
usort(
$some_array,
create_eval_closure(
// args, as name only; would lack of default value support be a problem?
array('a', 'b'),
// function body, as a static string
'return strcasecmp($a[$key], $b[$key]);',
// variables to "close over"
array('key' => $key)
)
);
Basically, it would be a bit like a parameterised SQL query: you can't actually prevent people interpolating into the strings anyway, but you can give them a safe mechanism that means they shouldn't need to.
--
Rowan Collins
[IMSoP]