Functional PHP 5.3 - What are Anonymous Functions and Closures?
recessframework.org
recessframework.org
As a byline, it is posted at recessframework. I did not know about the framework. Downloaded it gave it a spin and was impressed!
Ah thanks for that! I remember the guy posted a link here when Recess was in it's infancy. I gave it a spin but preferred more mature offerings :)
Time to give it another go I think.
Previously we've had to do some rather ugly things with "create_function" and lots of escaping in order to make arbitrary sort comparator functions.
An example of the old style:
private function makeCompare($field, $desc) {
return create_function('$a,$b', "
\$r = strcasecmp(\$a['$field'], \$b['$field']);
return " . ($desc ? '-1' : '1') . " * \$r;");
}
Not my proudest moment, to be sure.So someone clarify for me why this is any better. What am I missing?
Another property of lambdas is nested defines with the possibility to return an inner function (be it anonymous or not) from an outer one.
At last their lexical scope allows, in the inner/outer functions described above, to keep the scope of the outer function alive as long as the returned inner function is referenced. This allows to make them work as lightweight objects (or even to define an object system if you want to).
It's the same with references vs. pointers. You can't do any calculations with references, but you can with pointers.
In smalltalk and ruby closures are used extensively to define new control structures using the block syntax.
However, the functionality isn't the only thing. There are two notational conveniences that typically come along for the ride:
1) You can declare the function nested within another function. This is a necessary prerequisite to...
2) The associated structure is automatically created by the compiler based on what data the function uses in the surrounding context.
3) Just like the struct/fptr pair you might have created manually on the heap, you can return this function from another function with the data it captured coming along for the ride. That's generally were all the fun stuff happens :-)
To clarify this: See the recent "lambda" proposal for C++0x to see that same feature in the context of a Cish language, with the attendant modifications for manual memory management, stack based capture, etc.
function is_not_numeric($num){
!is_numeric($num);
}
array_map('is_not_numeric', array(1,3,5,'a','c',3));
The fact that php used to take a string as the callback and not an expression is seriously broken.Now (presumably), one can write:
array_map(function($x){ !is_numeric($x) }, array(1,3,5,'a','c',3));
Although, ideally it would be: array_map(!is_numeric, array(1,3,5,'a','c',3));I'm not just PHP-trolling here, either. There is a history in the PHP project of adding features to the language without any reference to how they will be made "safe". The PHP interpreter is notoriously unhelpful at catching even the simplest of bugs. This just seems like another ad-hoc feature added to the list of things that are likely to introduce subtle bugs that are undetectable until they are running on a production system somewhere.
I agree that PHP's house is on fire, but PHP has such a big house that I'm not sure it's noticed yet.
PHP, being the quirky language that it is, needs the use syntax to enable closures for cases where there are dynamic variable references. This is a bad example but illustrates the problem:
$foo = 'bar'; $fun = function() use ($foo) { $var = 'foo'; echo ${$var}; }; $fun(); // output 'bar'
$fun = function() { $var = 'foo'; echo ${$var}; }; $fun(); // fails
Sure, you could close over the entire local namespace but that's an efficiency nightmare and leads to unpredictable code.