Michael G Schwern wrote:
>
> The RFC proposes a <<< operator which would strip whitespace off the
> front of the here-doc. Problem is preserving indentation. We can
> merge the two.
Actually, the two started merged. :-) They were split up after there
were too many people for RFC 111 but against RFC 162. Personally, I'd
rather see the recipe method of:
print <<END_OF_DOC =~ s/^\s{0,5}//g;
(It's something like that) used for the "stripping leading whitespace"
issue.
> I've seen no reason to allow a semicolon other than "why not". Its a
> special case which adds no syntax sugar and simply represents
> unnecessary orthoginality. It just lets you be sloppy.
Well, it does add some consistency. Admittedly, there's not a huge
value-add so if it doesn't get in, hey, it doesn't get in. :-)
> 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".
If you have a potentially huge here doc it can help, just like a
potentially huge if statement:
if ( $cond ) {
# 200 lines pass
} # end if($cond) line 23
> I'm worried this might cause here docs to look too much like left shift
> operators. And consider the following ambiguity.
>
> use constant BAR => 2;
>
> $foo << BAR;
> Stuff
> BAR
>
> print $foo << BAR;
>
> The first is a here-doc. The second is a left shift. They look
> veeery close.
Well, the ambiguity you mention actually already exists in a similar
form; see Camel-3 p. 67. So I don't know that this would really hurt or
help the situation.
-Nate
