<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Mon, 20 May 2013 09:33:50 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Court Ewing's Blog: Forget Concatenation; Format your strings!]]></title>
      <guid>http://www.phpdeveloper.org/news/15138</guid>
      <link>http://www.phpdeveloper.org/news/15138</link>
      <description><![CDATA[<p>
On his blog today <i>Court Ewing</i> has <a href="http://epixa.com/2010/09/forget-concatenation-format-your-strings">posted a tutorial</a> about a different approach to merging strings while formatting them at the same time - using <a href="http://php.net/sprintf">sprintf</a> and <a href="http://php.net/printf">printf</a> for more than just a single-shot output.
</p>
<blockquote>
I do it, you do it, everyone does it! We all concatenate. If you're simply combining a few variables or constants together, concatenation is the way to go. After all, it is quick and easy, and who can complain about that? However, concatenation does have two serious drawbacks: any sort of string formatting must be done manually, and it is difficult to visualize the "goal" string when it is sufficiently complex.
</blockquote>
<p>
He talks about the benefits of string formatting over basic string concatination like how easy it makes casting variable values - multiple or single - without you having to cast them manually and append. He gives a few code examples of how it can be used for simple formatting and how it can make escaping data used in multiple spots easier. He also includes a SQL query example showing the difference between using <a href="http://php.net/sprintf">sprintf</a> and a normal concatinated statement.
</p>]]></description>
      <pubDate>Thu, 16 Sep 2010 08:38:35 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[Sara Golemon's Blog: How long is a piece of string?]]></title>
      <guid>http://www.phpdeveloper.org/news/5616</guid>
      <link>http://www.phpdeveloper.org/news/5616</link>
      <description><![CDATA[<p>
<i>Sara Golemon</i>, inspired by an IRC discussion has gathered together some of her thoughts on "using PHP's string interpolation without using an optimizer".
</p>
<p>
She <a href="http://blog.libssh2.org/index.php?/archives/28-How-long-is-a-piece-of-string.html">explains</a> 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.
</p>
<blockquote>
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.
</blockquote>
<p>
She <a href="http://blog.libssh2.org/index.php?/archives/28-How-long-is-a-piece-of-string.html">specifically mentions</a> the <a href="http://pecl.php.net/package/apc">APC</a> 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.
</p>
<p>
Of course, not everyone can install this pacakge, so she suggests an alternative:
</p>
<blockquote>
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.
</blockquote>]]></description>
      <pubDate>Mon, 19 Jun 2006 05:56:03 -0500</pubDate>
    </item>
  </channel>
</rss>
