On Thu, Apr 14, 2016 at 3:37 AM, Davey Shafik <da...@php.net> wrote:
> Whitespace inside of { } should not matter, the contents should be evaluated
> as an expression and it's results used to determine the variable name, so
> ${great} should also be $my as in the other cases.
>
Right. Which is why I'm conflicted on bug/not-bug/different-bug.
IMO, the label inside ${...} should either always be a variable name
(like HHVM handles it), or always be an expression. What we have is
"It's always an expression except in the one specific case of it being
a valid variable name, in which case that takes precedence. Since the
versions containing spaces aren't valid variable names, they fall back
on the more general expression handling.
So I'd be inclined to say "That exception to the rule is the problem",
except that this is variable interpolation behavior that goes ALL THE
WAY BACK, and I wouldn't break BC for the world.
So the question becomes: What's the right move going forward. My
inclination would be to either:
A: Ignore surrounding whitespace within the ${...} expression.
Essentially, adopt HHVM's output for these examples.
B: Throw an error on surrounding whitespace. This will make
discovering timebombs like these in existing code easier to catch.
In either case, if the programmer actually did want the
constant->variable double-interpolation, that could be easily achieved
via "${(foo)}" which disambiguated foo as a variable name from foo as
an expression.
-Sara
> Is this related to the use of quotes around string array keys inside
> strings?
>
> e.g. "$foo[great]" does not evaluate to $foo['my'] but to $foo['great'].
>
I don't think so... I have a feeling that's yet another weird oddity
to PHP parsing that's waiting to bite us in new and surprising ways.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
