# Constants in double-quoted strings - Thread: https://externals.io/message/41541 - Original archive: https://news-web.php.net/php.internals/41541 - Started by Josh on 2008-10-29T04:17:42+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #41541 — Josh — 2008-10-29T04:17:42+00:00 URL: https://externals.io/message/41541#41541 Hello, What is the chance of support for constants in double-quoted strings in PHP 5.3 or PHP 6.0? This is something I have wanted for some time now. Use cases: Writing an SQL query that makes use of a status field Syntax suggestions: Constants would need to be contained within curly braces. e.g. "SELECT ID, Name FROM Projects WHERE StatusID = {STATUS_ACTIVE} LIMIT {NUM_PER_PAGE} OFFSET {$offset}" The syntax would therefore be: '{', one or more of [-_a-zA-Z0-9], '}' If not constant is found, the string should be inserted directly. If that causes too much parsing issues, perhaps a symbol should be placed before or after the opening brace. e.g. "SELECT ID, Name FROM Projects WHERE StatusID = {#STATUS_ACTIVE} LIMIT #{NUM_PER_PAGE} OFFSET {$offset}" Regards, Josh --- ## #41543 — Arvids Godjuks — 2008-10-29T06:53:23+00:00 URL: https://externals.io/message/41541#41543 · In reply to: #41541 People, when you will start to learn that such approach is a mess? First, use ' ' instead of " " and format your SQL better and you woun't have any problems: a). It's more readable without syntax highlighting b). It's just faster. c). It's a good style. d). I think if that is easy to do, it would be implemented a long time ago. 2008/10/29 Josh > Hello, > > What is the chance of support for constants in double-quoted strings > in PHP 5.3 or PHP 6.0? > > This is something I have wanted for some time now. > > Use cases: > Writing an SQL query that makes use of a status field > define ('STATUS_ACTIVE', 1); > define ('NUM_PER_PAGE', 25); > $q = "SELECT ID, Name FROM Projects WHERE StatusID = " . STATUS_ACTIVE > . " LIMIT " . NUM_PER_PAGE . " OFFSET {$offset}"; > $res = mysql_query ($q); > ?> > > Syntax suggestions: > Constants would need to be contained within curly braces. e.g. > "SELECT ID, Name FROM Projects WHERE StatusID = {STATUS_ACTIVE} LIMIT > {NUM_PER_PAGE} OFFSET {$offset}" > The syntax would therefore be: > '{', one or more of [-_a-zA-Z0-9], '}' > If not constant is found, the string should be inserted directly. > If that causes too much parsing issues, perhaps a symbol should be > placed before or after the opening brace. e.g. > "SELECT ID, Name FROM Projects WHERE StatusID = {#STATUS_ACTIVE} LIMIT > #{NUM_PER_PAGE} OFFSET {$offset}" > > Regards, > Josh --- ## #41548 — pstradomski@gmail.com — 2008-10-29T09:01:47+00:00 URL: https://externals.io/message/41541#41548 · In reply to: #41543 W liście Arvids Godjuks z dnia środa 29 października 2008: > People, when you will start to learn that such approach is a mess? > First, use ' ' instead of " " and format your SQL better and you woun't > have any problems: > > define ('STATUS_ACTIVE', 1); > define ('NUM_PER_PAGE', 25); > $q = 'SELECT > ID, Name > FROM Projects > WHERE StatusID = '.STATUS_ACTIVE.' > LIMIT '.NUM_PER_PAGE.', '.$offset; > $res = mysql_query ($q); > ?> It's almost the same as original poster's version (except for $offset). > a). It's more readable without syntax highlighting > b). It's just faster. > c). It's a good style. > d). I think if that is easy to do, it would be implemented a long time ago. With regard to a and c - this is just your opinion, others might find it less readable (or indifferent). And for b - speed difference between ' and " should be negligable (esp. with opcode caches). I only worry it could break BC - people might have used "{SOMETEXT}" in strings and not expect it to be interpolated (I've done so myself). -- Paweł Stradomski --- ## #41549 — Dave Ingram — 2008-10-29T09:53:20+00:00 URL: https://externals.io/message/41541#41549 · In reply to: #41548 > I only worry it could break BC - people might have used "{SOMETEXT}" in > strings and not expect it to be interpolated (I've done so myself). > I've done that a lot, and I've seen quite a bit of templating code that does the same. My personal opinion is that interpolating constants would just lead to trouble, one way or another. Even something like "{#SOMETEXT}" could be problematic. I would definitely discourage interpolation without some sort of sigil though... barewords (in brackets or not) are too likely to break BC. Dave --- ## #41550 — Josh — 2008-10-29T10:45:29+00:00 URL: https://externals.io/message/41541#41550 · In reply to: #41549 Dave, how is a variable name any less a bareword than a constant name? Thats what the backets were for, perhaps combined with a symbol to make it even less likely, and of course if the constant is not found in the symbol table, the constant name would be outputted directly. > > > […] > I've done that a lot, and I've seen quite a bit of templating code that > does the same. > > My personal opinion is that interpolating constants would just lead to > trouble, one way or another. Even something like "{#SOMETEXT}" could be > problematic. I would definitely discourage interpolation without some > sort of sigil though... barewords (in brackets or not) are too likely to > break BC. > > > Dave --- ## #41556 — Dave Ingram — 2008-10-29T14:47:43+00:00 URL: https://externals.io/message/41541#41556 · In reply to: #41550 Josh wrote: > Dave, how is a variable name any less a bareword than a constant name? > A bareword (in my opinion) is a word without a sigil (e.g. a leading $), so the way that you would write a constant normally in PHP. What I was trying to say is that having bareword-style interpolation ("{MYCONST}") is much more likely to break BC than the "{#MYCONST}" style. > Thats what the backets were for, perhaps combined with a symbol to > make it even less likely, and of course if the constant is not found > in the symbol table, the constant name would be outputted directly. > But would it raise a warning, as PHP currently does for unrecognised constants? If not, it could be argued that this would make subtle typos harder to spot. Dave