It is expected behavior. Although I agree it is not very handy that this is not possible. Making this a feature request.

Derick

This behaviour is documented in the strings section, subsection heredoc. 

I agree that this is quite annoying and strange. It can be easily modified, for example to allow anything afterwards. But this could break BC (though not likely):

$bla = <<<HEREDOC
Text 
text
HEREDOC is great!
text
HEREDOC;

Other solutions would be quite arbirary (as is the current solution by the way). Most consistent would be allowing a heredoc-string at all places where a quoted string is also allowed.

Patch available here: 
http://www.A-Eskwadraat.nl/~jeroen/php/looser_heredoc.diff
which changes behaviour to:

A heredoc is considered closed when the heredoc identifier appears directly after a newline. Remaining characters are allowed, provided they are invalid identifyer characters.

Example:
<?php

mail('jeroen@php.net', 'heredoc test', <<<TEXT
Hello Jeroen,

Greets!
TEXT, 'Cc: bla@example.com');
?>

And this works:
<?php
echo <<<HEREDOC
bla
HEREDOCUMENTATION;

HEREDOC; // here the heredoc ends
?>

But this doesn't:
<?php
echo <<<HEREDOC
bla
HEREDOC UMENTATION;

HEREDOC;
?>

for the same reason as this is:
echo "bla" UMENTATION;
causes a parse error.

Here's a quick patch which just allows text *after* the 
semicolon, and doesn't appear to affect anything else, so
BC shouldn't be a problem. stat@php.net told me before that
this is 'intentional', but no-one has yet explained why...

Note that this patch may not be the best solution, but it
does illustrate what I'm after.

Torben

Index: zend_language_scanner.l
===================================================================
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.43
diff -u -r1.43 zend_language_scanner.l
--- zend_language_scanner.l     2002/01/06 15:21:09     1.43
+++ zend_language_scanner.l     2002/01/29 02:54:16
@@ -1256,7 +1256,7 @@
 }
 
 
-<ST_HEREDOC>^{LABEL}(";")?{NEWLINE} {
+<ST_HEREDOC>^{LABEL}(";")? {
        int label_len;
        unsigned char unput_semicolon;

Yeesh. Scratch that. :) The issue remains but the patch I 
just posted here indicates a seious need for supper.


Torben

This would be very useful to change.  Additionally if/when this is closed, Bug #5804 is a duplicate of this.  Thanks,

Steve

IIRC. This has been discussed and we decided not to have this change.