Hacker News Reader

Comment by noahlt | Hacker News Reader

Can anyone explain why this is so terrible? To me, it seems like Lisp, but backwards: in Lisp, you have symbols, which normally evaluate to their values unless they are quoted. In PHP, you have strings, which normally evaluate to themselves unless they are 'unquoted' with $.

View on HN

The feature isn't bad, but there are several warts. The '$' is not a prefix operator on strings. The following is a syntax error:

    $"test";

It turns out that '$' can only operate on an identifier or another '$' expression. The '${...}' syntax, aside from being more readable and less likely to be accidentally encountered, is more like an operator:

    ${"test"}; // equivalent to $test

The decision to keep (and only warn against) unescaped strings past the introduction of an incompatible feature (constants) is inexcusable. It creates oddities:

    $test = 'foo';
    $foo = 42;
    echo $test . " ${test} " . ${test} . " " . $$test . "\n";

This generates a notice and prints, "foo foo foo 42". But then:

    $test = 'foo';
    $foo = 42;
    define('test', 'foo');
    echo $test . " ${test} " . ${test} . " " . $$test . "\n";

This will print, "foo foo 42 42". (Note also the difference between the meaning of ${...} within string interpolation versus outside of it.) Is this all understandable? Sure. Is it good? No.

> The decision to keep (and only warn against) unescaped strings past the introduction of an incompatible feature (constants) is inexcusable.

It's so easy to turn those warnings into exceptions. I don't think I've seen any project in the wild that does anything meaningful with unescaped strings.

I suspect it has more to do with the reputation (underserved or not) of the typical PHP programmer. This construct offers some powerful meta-programming capabilities when properly used, but in the hands of unskilled practitioners, could be turned about to write unholy and perverted softwares.

Reply on news.ycombinator.com