Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92332
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
To: internals@lists.php.net
References: <CAESVnVoFQUe7g4DGkszG2gR3gT3EhwEe=+CaUksUcRp0metR2A@mail.gmail.com>
 <CANaX5nfHZGKwqO=1fvYBoEJjqceLX99FsWheQzH3=cbE5-UW5w@mail.gmail.com>
 <CAESVnVpHfkb6yexNN2mZz3Dqv-_4S+yUoyba1Hm+S45NGH+cAg@mail.gmail.com>
 <04125064-C4C4-43C1-8EC0-8CD633E3A0F2@simon.geek.nz>
Message-ID: <5710C481.8060800@gmail.com>
Date: Fri, 15 Apr 2016 11:37:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <04125064-C4C4-43C1-8EC0-8CD633E3A0F2@simon.geek.nz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Interpolation using ${} syntax with spaces inside the
 braces
From: rowan.collins@gmail.com (Rowan Collins)

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]