... and to think that my contempt for PHP couldn't be increased.

Wow. This is the anti-Scheme. It's like they took everything good in language design and decided to do the exact opposite. "Let's make a function that has the side effect of introducing variables into scope. That's a great idea."

Oh, Bog....

> This is the anti-Scheme.

Since when is Scheme the arbiter of what is good or bad?

PHP lets you do this, or not do this, your choice. Like C, PHP doesn't tell you what to do, it's up to you.

That's why people actually use it.

Just because something is being used widely does not make it right, nor should it be held up as a fine example of design.

Language hacks like the one we're discussing are fine IF:

- You work with people who avoid bad features.

- You can avoid using code that uses bad features (less of a problem, until you have to debug things and then you're in a world of hurt).

- The features are not short-sighted hacks that prevent the language from moving forward (e.g., eliminate the opportunity to make things faster through dynamic compilation or whatever).

Scheme is a great language that is not useful in the real world, while PHP is a terrible language that happens to be in wide use. Neither of these positions are unique, and honestly I'd much rather use a bad language with good tooling than a great language with poor support. But I will continue to point out PHP's flaws, which are many and just howling bad, and work towards improving the alternatives.

If this is the quality of the argument then I have nothing to concern myself with.

Your post might be [slightly] humorous, but as an argument against PHP language constructs it fails miserably.

It really doesn't. Especially when you see people pulling out the double claw hammers at your company.

Features that have limited real benefits with lots of risk get abused all the time. They are the retarded tools of the world creating technical debt for everybody else and they should be retired.

Extract is one of the stupidist language feature conceived precisely because it puts something so ripe for abuse into the hands of idiots. It even has a simple name that practically encourages its abuse.

Yup, then you see people building sine wave roads for the square wheels they build last week.

Or making critical parts of infrastructure work by a cron job that calls wget.

For some reason PHP needs extract, because a dictionary just won't do.

  foo["var_x"]

  // for some reason needs to be:

  $var_x

I think you mean catenaries, not sine waves.

That's not not how 'let' works, you can't do that with 'let'. You most definitely should blame the tools here.

You're right, let is a macro so you can't pass binding forms from a variable, my mistake. But surely Scheme has some function for binding variables to the local scope...

My point is that trusting user input is the error, not having the ability to play with the scope.

Scheme has forms that add bindings to the local scope -- local defines -- but they're similar in spirit to let. There aren't any such functions in standard Scheme, and I don't know of any major implementation that has any. It's not clear how they would interact with macros or macro hygiene, and they would do unpleasant things to lexical scope which is Scheme's original schtick.

The problem is when unexpected variables are overwritten. It would be better to have a mandatory list of allowed variables that can be extracted.

    $login = '1234';
    extract(array('login'=>true, 'messsage'=>'hacker'), 'message');
    var_dump($login_, $message);
    // => $login='1234', $message='hacker'

(pardon my rusty PHP)

> variables are overwritten. It would be better to have a mandatory list of allowed variables that can be extracted.

You can set the EXTR_SKIP flag to do something like that. There are a bunch of other flags as well to control how it works.

Or you could do this:

    function qux() { return [$foo, $bar, $baz]; }

    list($foo, $bar, $baz) = qux();

The problem with this is that it leaves things without any obvious, canonical, name. You have to read a bunch of code to figure out what's going on and a change in the values returned may result in subtle errors.

Coffeescript has a really neat destructuring operator for this kind of thing:

    qux = () -> {blah: "a", blorp: "b", zoop: "c"}
    {blah, blorp, zoop} = quz()

Yah, I do that when it's just a few variables, but it gets unmanageable when the number starts increasing.

It's also error prone if you have several feeder/user functions since you have to change them in multiple places.

Or if you have two code paths that end up with two different sets of variables (probably controlled by a semaphore variable) then this won't work.

This smells like an antipattern. I can't imagine a reason for wanting to do this that isn't a result of some very poor architectural choices.