While I can't immediately think of a practical problem with this, I'm hesi
tant at the idea of adding yet more ways of quoting strings; it means more
for users to learn, more for third party parsers to implement (including ex
actly the syntax highlighting tools you're going to help), and in the worst
case, more edge cases that can lead to security issues
More for users to learn? Don't you mean less, haha? This is an
arbitrary limitation of heredoc, that we can remove (it might not be
arbitrary from a yacc perspective, someone would have to explain that
if so).
I don't know about other editors, but PhpStorm at least also recognises an
in-line comment explicitly labelling any string, which if anything seems m
ore explicit:$query = /** @lang mysql */"SELECT * FROM foo";
Pja. I wouldn't call it more or less explicit than heredoc notation, personally.
Olle
More for users to learn? Don't you mean less, haha? This is an
arbitrary limitation of heredoc, that we can remove (it might not be
arbitrary from a yacc perspective, someone would have to explain that
if so).
I don't think the rules for heredoc are arbitrary, but they are quite
specific: the end delimiter has to appear at the start of a line, so
it can appear anywhere else in the text without prematurely ending the
string:
$foo = <<<FOO
This is a normal heredoc
this is not the end FOO
this is:
FOO;
(Prior to PHP 7.3, only certain characters could appear after the end
delimiter, but that's now more relaxed, and there's some clever rules
around indenting.)
As far as I can see, a single-line heredoc would need to be a new
syntax, with its own syntax rules. Something like
- If there is at least one non-whitespace character after <<<FOO but
before the next newline, this is a one-line heredoc - If so, the heredoc content is everything up to and including the last
occurrence of "FOO", followed by an optional semicolon, and a required
newline - If "FOO" does not appear again before the next newline; or there is
other text between "FOO" and the newline, that is a syntax error
For instance, the following would presumably be valid:
$foo = <<<FOO one-line heredoc ending at end of line FOO
;
$foo = <<<FOO one-line heredoc with semicolon FOO;
$foo = <<<FOO this is a heredoc containing FOO and other text FOO;
$foo = <<<FOO // I guess this is a string not a comment? FOO;
But the following would not:
$foo = <<<FOO one-line heredoc not ended
$foo = <<<FOO this heredoc contains FOO and then doesn't end
$foo = <<<FOO mixing one-line and multi-line syntax doesn't make sense
FOO;
$foo = <<<FOO this heredoc looks like it ends FOO . 'but actually it
doesn't';
Perhaps you disagree with some of those rules and examples, but
hopefully can see that the rules would need defining, and therefore
learning.
I don't know about other editors, but PhpStorm at least also recognises an
in-line comment explicitly labelling any string, which if anything seems m
ore explicit:$query = /** @lang mysql */"SELECT * FROM foo";
Pja. I wouldn't call it more or less explicit than heredoc notation, personally.
It's more explicit in the sense that it is syntax dedicated for that
purpose, in a standard format. If I write <<<FOO hello FOO, there's no
way to know if "foo" is the name of a language I'm hoping to label, or
just a token which I know doesn't appear in my content; if I write /**
@lang foo */"hello", there's no ambiguity, even if you've never heard of
"foo" as a language.
Regards,
--
Rowan Tommins
[IMSoP]
2022-09-20 11:54 GMT+02:00, Rowan Tommins rowan.collins@gmail.com:
More for users to learn? Don't you mean less, haha? This is an
arbitrary limitation of heredoc, that we can remove (it might not be
arbitrary from a yacc perspective, someone would have to explain that
if so).I don't think the rules for heredoc are arbitrary, but they are quite
specific: the end delimiter has to appear at the start of a line, so
it can appear anywhere else in the text without prematurely ending the
string:$foo = <<<FOO
This is a normal heredoc
this is not the end FOO
this is:
FOO;
Ya ok, this kills my idea. If heredoc was designed from start so that
the delimiter would not be allowed at all in the text, then it would
make sense. Weird that they did it like that, would be easy enough to
come up with a unique delimiter so that it would not cause a
problem... Obviously it can't be changed now without breaking
backwards compatibility.
Our product still supports PHP 7.2 sadly, but that's our own problem. :)
Thank you.
Olle
Ya ok, this kills my idea. If heredoc was designed from start so that
the delimiter would not be allowed at all in the text, then it would
make sense. Weird that they did it like that, would be easy enough to
come up with a unique delimiter so that it would not cause a
problem... Obviously it can't be changed now without breaking
backwards compatibility.
For what it's worth, the "they" in question are the authors of the early
Unix shells in the 1970s - from a quick search, it seems like the Bourne
shell was the first to implement "here document" syntax, sometime around
1979. As the name suggests, they were not for defining strings, but for
entering entire text files embedded in a script or interactive shell
session.
In that context, the original format is actually elegantly minimal:
content is read one line at a time; if it exactly matches the delimiter,
stop; else, add the line to the file buffer. No actual parsing is required.
Regards,
--
Rowan Tommins
[IMSoP]