Lars Strojny has posted about a the new element that's been introduced in the PHP 5.3 branch - NOWDOC:

PHP 5.3 introduces a new syntax element, NOWDOC. If you know HEREDOC, NOWDOC is easy to understand: it is in fact HEREDOC taken literally. Whily variables are expanded in HEREDOC, in NOWDOC they are not.

NOWDOC is basically a HEREDOC except for one thing - no parsing is done inside of it, making it good for echoing out PHP code (that would otherwise need to be escaped all over).

Christopher Jones has posted about an update to the development for PHP 5.3 that makes escaping SQL even easier in scripts - NOWDOCS.

Escaping quotes or other meta characters in SQL can be painful unless you get lucky with your quoting style. [...] Even with PHP's "Heredoc" syntax something will need escaping, but with PHP 5.3's new "Nowdoc" syntax no escaping is needed.

The only difference between HEREDOC and NOWDOC is that the initial keyword (like the first END in this statement: <<<'END' text here END;) that can make worrying about complex quoting rules a thing of the past.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.

Sara Golemon, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".

She explains how a simple string (an echo statement) is interpreted into a simple compilation structure. Her next step, though (placing a variable inside a string) yields something that seems more complex than it should be. A concatination example simplifies things down a bit, but, oddly enough, it gets even better when a comma is used instead of a period to concatinate. She also gives an example of a heredoc statement that doesn't conform to the interpolation standards you'd think.

Why does this happen? Because there are about a dozen ways that a variable can be hidden inside an interpolated string. Similarly, when looking for a heredoc end-token, the token can be an arbitrary length, containing any of the label characters, and may or may not sit on a line by itself. Put simply, it's too difficult to encompass in one regular expression.

She specifically mentions the APC caching system and its built-in optimizer to help with some of these issues. It pulls the interpolations back down to a size they should be and anticipating operations by pre-resolving things like constants and scalar expressions.

Of course, not everyone can install this pacakge, so she suggests an alternative:

You can still avoid 90% of the INIT_STRING/ADD_STRING dilema by simply using single quotes and concatenation (or commas when dealing with echo statements). It's a simple trick and one which shouldn't harm maintainability too much, but on a large, complicated script, you just might see an extra request or two per second.