Simon Welsh wrote on 15/04/2016 00:52:
When not inside a string, the inside of the ${...} is always treated as an
expression, by both PHP and HHVM (https://3v4l.org/i2kOP), so that looks like
the
“correct” handling for inside a string.
The in-quotes behaviour makes sense when you consider the use cases it
solves, e.g.
$foo = 'percent';
echo "${foo}age";
Arguably, the alternative bracketing style is clearer here, and doesn't
have the name-expression conflict:
$foo = 'percent';
echo "{$foo}age";
So possibly you're right - in an ideal world ${ ... } should evaluate an
expression whether inside a string or out, and {$...} can be used inside
a string for isolating variables.
But given the horrendous BC issues of changing that now, I'm inclined to
say that surrounding whitespace should be an error, and force the user
to use less ambiguous syntax.
It occurs to me that this problem is made worse by the "implicit
constant definition" where an undefined constant becomes a string.
Removing the definition of the constant from the example, and
suppressing notices, gives identical output in all versions:
https://3v4l.org/3i2El Leave the notices on, though, and you'll see
they're getting to that answer in different ways - PHP is mapping
expression -> undefined constant -> string -> variable name. So you
could have code that works one way for years, then define a global
constant with the same name as the local variable, and suddenly
everything would go haywire.
I would love to see that implicit definition officially deprecated, but
that's for another thread...
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
