Nowdocs revised

18 years ago by Gwynne Raskind — view source

unread

I've taken my original nowdocs patch and revamped it to be much more
efficient and functional. This version:

Parses nowdocs as constant strings rather than ADD_STRING opcodes.
Allows the flex scanner do less work.
Enables nowdocs to be used in static_scalar contexts, such as class
constants and static variable initializers.
Includes more tests than before.
Is fully compatible with the most recent CVS checkouts for HEAD and
PHP_5_2, and also merges cleanly into a 5.2.3 source tree.
Breaks zero regression tests out of all 3000 or so.

The patch also cleans up the zend_language_scanner.l code a little
bit, cosmetically speaking, and the PHP_5_2 patch updates the scanner
by factoring out single-quoted string scanning, as HEAD already did.
The patch is available for download at <http://
phpdoc.gwynne.dyndns.org/nowdocs.zip>;, and browsable at <http://
phpdoc.gwynne.dyndns.org/nowdocs/>;.

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

17 years ago by Gwynne Raskind — view source

unread

Did you get any further with merging this? It would help users of
the XQuery language.

If I understand your intent, I would be able to change the code
fragment
below to use a nowdoc, and not have to escape the XQuery $i variables.

Chris

<?php

$c = oci_connect("hr", "hrpwd", "localhost/orcl");

$xq = <<<END
select column_value
from xmltable('for $i in ora:view("locations") return $i')
END;

$s = oci_parse($c, $xq);
oci_execute($s);
while ($row = oci_fetch_row($s))
var_dump($row);
?>

I didn't get any further, no :(. The decision of whether to merge the
nowdocs patch is out of my hands now, since I don't have source
karma. However, since the main thing standing in the way of its
implementation was concern over the usefulness, your comment is very
helpful, and I'd like to open the topic for discussion again on the
list, if no one out there has any objection :)

-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."

17 years ago by Richard Quadling — view source

unread

Did you get any further with merging this? It would help users of
the XQuery language.

If I understand your intent, I would be able to change the code
fragment
below to use a nowdoc, and not have to escape the XQuery $i variables.

Chris

<?php

$c = oci_connect("hr", "hrpwd", "localhost/orcl");

$xq = <<<END
select column_value
from xmltable('for $i in ora:view("locations") return $i')
END;

$s = oci_parse($c, $xq);
oci_execute($s);
while ($row = oci_fetch_row($s))
var_dump($row);
?>

I didn't get any further, no :(. The decision of whether to merge the
nowdocs patch is out of my hands now, since I don't have source
karma. However, since the main thing standing in the way of its
implementation was concern over the usefulness, your comment is very
helpful, and I'd like to open the topic for discussion again on the
list, if no one out there has any objection :)

Being able to code templates within PHP rather than as an external
file without any escaping or variable expansion is useful.

--

Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

17 years ago by Derick Rethans — view source

unread

I didn't get any further, no :(. The decision of whether to merge the nowdocs
patch is out of my hands now, since I don't have source karma. However, since
the main thing standing in the way of its implementation was concern over the
usefulness, your comment is very helpful, and I'd like to open the topic for
discussion again on the list, if no one out there has any objection :)

I don't see why this can not go into 5.3 once that branch is open. It
seems pretty useful to me.

regards,
Derick

17 years ago by Stanislav Malyshev — view source

unread

I didn't get any further, no :(. The decision of whether to merge the
nowdocs patch is out of my hands now, since I don't have source karma.
However, since the main thing standing in the way of its implementation
was concern over the usefulness, your comment is very helpful, and I'd
like to open the topic for discussion again on the list, if no one out
there has any objection :)

I think we can have it in HEAD and maybe in 5.3 - though it raises
questions about compatibility (code not parsing in certain PHP versions
and parsing in others might be a problem). Not sure if <<<~ is the best
syntax - it's definitely not obvious, maybe we could think of something
better.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Pierre — view source

unread

I didn't get any further, no :(. The decision of whether to merge the
nowdocs patch is out of my hands now, since I don't have source karma.
However, since the main thing standing in the way of its implementation
was concern over the usefulness, your comment is very helpful, and I'd
like to open the topic for discussion again on the list, if no one out
there has any objection :)

I think we can have it in HEAD and maybe in 5.3 - though it raises
questions about compatibility (code not parsing in certain PHP versions
and parsing in others might be a problem).

I don't see a difference between a "fatal error call to undefined
function" and or a parse error. It can go without problem in 5.3.

Not sure if <<<~ is the best
syntax - it's definitely not obvious, maybe we could think of something
better.

<<< was never obvious, there is no obvious string to use in this case
(not obvious for everyone and his mother).

--Pierre

17 years ago by Stanislav Malyshev — view source

unread

I don't see a difference between a "fatal error call to undefined
function" and or a parse error. It can go without problem in 5.3.

Ah, there is a difference - you can do function_exists to check for a
function, but you can do nothing if your file doesn't parse.

<<< was never obvious, there is no obvious string to use in this case
(not obvious for everyone and his mother).

Perl does <<FOO and <<'FOO' and I think in this case difference is more
clear. I'm not sure this is the way, but it can be an option. Everybody
is welcome to propose - maybe it will be as much fun as the namespace
separator thread ;)

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Pierre — view source

unread

I don't see a difference between a "fatal error call to undefined
function" and or a parse error. It can go without problem in 5.3.

Ah, there is a difference - you can do function_exists to check for a
function, but you can do nothing if your file doesn't parse.

True, but the result is the same. The new functions/classes can't be
used (only some rare additions can be efficiently emulated in user
land).

<<< was never obvious, there is no obvious string to use in this case
(not obvious for everyone and his mother).

Perl does <<FOO and <<'FOO' and I think in this case difference is more
clear. I'm not sure this is the way, but it can be an option. Everybody
is welcome to propose - maybe it will be as much fun as the namespace
separator thread ;)

In this case, it will be yet another "Mark all as read" thread :-)

Cheers,
--Pierre

17 years ago by Stanislav Malyshev — view source

unread

True, but the result is the same. The new functions/classes can't be
used (only some rare additions can be efficiently emulated in user
land).

Yes, but you still have option of working around it. Right now we don't
have an option to work around new syntax. I hate to rain on your parade,
because I think this functionality is good and would have a lot of good
uses, but I'm worried about creating code that runs in one 5.x and can't
be even compiled by another. There can be a lot of problems with
external tools, too.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Pierre — view source

unread

True, but the result is the same. The new functions/classes can't be
used (only some rare additions can be efficiently emulated in user
land).

Yes, but you still have option of working around it. Right now we don't
have an option to work around new syntax. I hate to rain on your parade,
because I think this functionality is good and would have a lot of good
uses, but I'm worried about creating code that runs in one 5.x and can't
be even compiled by another. There can be a lot of problems with
external tools, too.

I agree about codes not running in the same "bug fixes" branch.
However I don't see a problem to introduce this patch in 5.3.0 (think
about "b" introduced in 5.2.x).

--Pierre

--

I think we can have it in HEAD and maybe in 5.3 - though it raises questions about compatibility (code not parsing in certain PHP versions and parsing in others might be a problem). Not sure if <<<~ is the best syntax - it's definitely not obvious, maybe we could think of something better.

Perl does <<FOO and <<'FOO' and I think in this case difference is more clear. I'm not sure this is the way, but it can be an option. Everybody is welcome to propose - maybe it will be as much fun as the namespace separator thread ;)

I think we can have it in HEAD and maybe in 5.3 - though it raises
questions about compatibility (code not parsing in certain PHP versions
and parsing in others might be a problem). Not sure if <<<~ is the best
syntax - it's definitely not obvious, maybe we could think of something
better.

Perl does <<FOO and <<'FOO' and I think in this case difference is more
clear. I'm not sure this is the way, but it can be an option. Everybody
is welcome to propose - maybe it will be as much fun as the namespace
separator thread ;)