Amen to the below. So can we have an RFC 111 (v4) that gets rid of allowing
stuff after the terminator? Even the ";" afterward seems useless... the ";"
should be at the end of the statement, not the end of the here doc. The only
improvement to here docs I see in this RFC is to allow whitespace before/after
the here doc terminator. The rest is handled adequately and consistently today,
and Tom's dequote is adequate to eliminate leading white space... especially
among people who cannot agree that a tab in a file means "mod 8" (which it
does).
Michael G Schwern wrote:
> > > I can't think of much else I'd want to comment about the end of a
> > > here-doc than "this is the end of the here-doc" which is about as
> > > useful as "$i++ # add one to $i".
> There's a big difference. Every code block ends with a '}'. Every
> here doc ends with its own custom tag. Thus to state:
>
> print <<EOF;
>
> Four score and seven years ago...
>
> EOF # end of print <<EOF line 23
>
> can currently be better written as:
>
> print <<GETTYSBURG_ADDRESS
>
> Four score and seven years ago...
>
> GETTYSBURG_ADDRESS
>
> The tag itself describes what the text is, similar to the way a
> well-named variable describes what's inside of it and removes the need
> for a descriptive comment. At a glance one can tell that
> 'GETTYSBURG_ADDRESS' closes the here-doc containing the Gettysburg
> Address, without having to maintain a comment. (I guarantee the line
> number mentioned in the comment will not be maintained.)
>
> Another reason for wanting to comment the closing of a code block is
> nesting. Simply searching for the previous '{' will not work.
> Here-docs cannot be nested and do not have this problem. Simply
> searching backwards for your here-doc tag will always work.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
