So... not that telling then.
So... not that telling then.
Of the C "dark corners" that are problematic, it'd be extremely rare to run into them in most real-world code. You'd have to intentionally go out of your way to write code that will trigger them, and this code often looks obviously suspicious.
It's very much the opposite with JavaScript and PHP. A world of pain and danger opens up the moment you do something as simple as an equality comparison. The problems that can and will arise are well documented, so I won't repeat them here, but it's a much worse (and unavoidable) situation than when compared to C, C++, Java, C#, Python, Ruby or other mainstream languages.
http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
string create_function ( string $args , string $code )
"Creates an anonymous function from the parameters passed, and returns a unique name for it."
So there you are. Of course you can choose to be an anonymous value, but you'll get a name assigned by the state, for free. :-) Fascinating logic, captain.
create_function was a way to
A) not having to define a function separately
B) not getting problems with the function being re-defined, since each call would create a new function
C) fake closures by generating code.
All this should be moot points by now, since PHP has real anonymous functions with closures,
But I suppose that goes naturally hand in hand with the cargo cult approach to language design.
That's why it would be a fake closure.
$foo = someNumber();
create_function('', 'return '.$foo.';');
You would generate a new string to be evaluated as the function body each time.> talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is.
I think you read too much into this. The point of an anonymous function isn't to make it not have a name, but to be able to define it where it is needed instead of referring to some specific function name in your code.
It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable.
$foo = 42;
$bar = 'foo';
print($$bar); // Prints 42.Actually, its point is to make it a value that can be referenced from any number of bindings (associations between names and values) in any number of scopes. What you're saying is just a consequence of this.
"It also fits well with the way PHP handles "pointers", by storing the name of a variable in another variable."
Which only shows the deficiency, since any such indirect reference should never refer to a name, but to a binding instead.
But about those dark corners, I guess the point wasn't to present any particularly nasty gotchas, but rather some precious little lesser known tricks. C has plenty of very well known features you can be bitten by (mostly related to memory management, of course). While the presentation reiterates over some of them, the most valuable parts are about various _good_ parts of the language which are rarely heard of (viz. the usage of `static` inside brackets).