<?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>Sat, 18 May 2013 01:59:12 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Nikita Popov's Blog: Scalar type hinting is harder than you think]]></title>
      <guid>http://www.phpdeveloper.org/news/17638</guid>
      <link>http://www.phpdeveloper.org/news/17638</link>
      <description><![CDATA[<p>
In <a href="http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think">this new post</a> to his blog <i>Nikita</i> talks about scalar type hinting and why it's harder than most people think to accomplish.
</p>
<blockquote>
One of the features originally planned for PHP 5.4 was scalar type hinting. But as you know, they weren't included in the release. Recently the topic has come up again on the mailing list and there has been a hell lot of discussion about it. Yesterday ircmaxell published a <a href="http://blog.ircmaxell.com/2012/03/parameter-type-casting-in-php.html">blog post about his particular proposals</a>. The reactions on <a href="http://www.reddit.com/r/PHP/comments/qiniv/parameter_type_casting_in_php/">reddit</a> were mixed. On one hand it is clear that people do really want scalar type hints, on the other hand they didn't seem to like that particular proposal.
</blockquote>
<p>
He gets into some of the details of some of the current proposals and their problems like the strict versus loosely-typed nature of PHP and type hinting that was included but not enforced. One he does like, however, is one based on casting - how the variable ends up being cast rather than the specific type it is when it comes into the function/method. This one still has its flaws, so he suggests another method - weak type hints but with stricter input validation (without casting). He also briefly mentions something called "box based type hinting" that would allow users to define their own hinting rules.
</p>
<p>
Don't worry - code examples (pseudo-code obviously) <a href="http://nikic.github.com/2012/03/06/Scalar-type-hinting-is-harder-than-you-think">are included</a> for each of these proposals to help you understand the differences.
</p>]]></description>
      <pubDate>Wed, 07 Mar 2012 10:03:47 -0600</pubDate>
    </item>
    <item>
      <title><![CDATA[Tobias Schlitt's Blog: Funny speed considerations]]></title>
      <guid>http://www.phpdeveloper.org/news/8757</guid>
      <link>http://www.phpdeveloper.org/news/8757</link>
      <description><![CDATA[<p>
<i>Tobias Schlitt</i> <a href="http://schlitt.info/applications/blog/index.php?/archives/565-Funny-speed-considerations.html">offers a helpful hint or two</a> for "speeding up" your application in the form of comparison operators.
</p>
<blockquote>
The fact that type save comparisons (ala ===) are faster in PHP than the normal comparison operator (ala ==). The reason for this is simply, that PHPs loosly-typed-ness-auto-cast-code is not even touched with ===
</blockquote>
<p>
He also points out an interesting condition that saves a bit of computing time - comparing the isset() of a variable to true over the count() to zero. Some of his <a href="http://schlitt.info/misc/bench_res.txt">benchmarking</a> (<a href="http://schlitt.info/misc/bench.txt">code</a>) shows this in action.
</p>]]></description>
      <pubDate>Mon, 01 Oct 2007 12:04:00 -0500</pubDate>
    </item>
  </channel>
</rss>
