I'm not sure about that. Not using "restrict" properly can lead to extremely hard-to-diagnose errors which can only be resolved by reading the generated assembler. I've seen several C programs that use "restrict" everywhere as a magic "go faster" device without understanding what it means...
The automatic conversions in JavaScript and PHP seem pretty harmless by comparison.
>Not using "restrict" properly can lead to extremely hard-to-diagnose errors
But "restrict" is a low-level micro-optimization, those tend to be tricky. I don't think a sane C programmer would sprinkle that keyword all across the source base, because as you have pointed out it can cause hard-to-diagnose errors.
In contrast, the automatic conversions in JavaScript and PHP are an "always on" feature you cannot avoid.
It's obviously JavaScript and PHP that are being referred to.
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.
Agreed. Everytime i get back to C it's like coming back home. But first you must study it hard to make it your home. On the other hand javascript (lang i'm using at current job) is like living 'Groundhog Day' with everyday finishing with suicide. Well, not saying javascript is bad language, there are some really great things about it, but it's designed with a loaded gun put on your head all the time :-) I'd also put C++ on list of dangerous languages, because it is trying to fix C problem while introducing OOP (and in newsest standard lambdas and others), so now you have huge base for new and exciting set of ways to kill yourself. It's not even funny that simple languages like lua are getting more users everyday.
"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.
In this case it isn't so weird, since PHP pre 5.3 didn't have first class functions. To pass a function around, you would use a variable containing a string of it's name.
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,
That's true (except for C), because I can't see how a create_function-defined function closes over its environment), but what I had in mind was the way in which the author of the documentation, obviously one of the PHP core developers, talks casually about "returning the name of an anonymous function". It shows just how much twisted the logic of these people is.
But I suppose that goes naturally hand in hand with the cargo cult approach to language design.
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.
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).
The automatic conversions in JavaScript and PHP seem pretty harmless by comparison.