5 ms·

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

by noahlt 16y ago

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 $.

jlangenauer 16y ago
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.
spoondan 16y ago
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.
- wvenable 16y ago
  > 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.

by noahlt 16y ago

jlangenauer 16y ago

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.

spoondan 16y ago

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.

wvenable 16y ago
> 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.