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 blog post about his particular proposals. The reactions on reddit 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.

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.

Don't worry - code examples (pseudo-code obviously) are included for each of these proposals to help you understand the differences.

I was confused recently to realise that I had accidentally called a static method in PHP dynamically from another part of my code; I expected PHP to output warnings when this is done. On closer inspection I discovered that: static functions can be called dynamically and dynamic functions generate an E_STRICT error if called statically.

She illustrates with some sample code that, when run with E_ALL and E_STRICT throws a warning from the strict side about calling a non-static method statically. She also talks about why it throws this warning for the non-static call on a static method. She also explains why, when a static method is called dynamically, no warning is thrown.

Without a little background in programming languages or computer science in general, it's entirely possible that typing systems are not something that have crossed your mind. I thought I'd take a blog entry to share some of my thoughts on how it's affecting the creation and evolution of languages.

He walks through history a bit, mentioning C, Java, Python and PHP and how they differ in their default type handling. He especially focuses on the "blurred line" between strong and weak typing and how some if offers special features to the language that uses the method.

As of PHP 5.2.1, json_decode() no longer follows the published standards for JSON-encoded texts. Why not? For no reason other than the convenience of those ignorant of JSON standards.

His complaint stems from the results of a vat_dump statement - prior to this version it would give a NULL, but now it returns a "bool(true)" value back, resulting in some breakage of previous scripts. He spends the rest of the post explaining his voyage through the JSON world and how things are supposed to behave. He also digs a little deeper into the var_dump issue and why he thinks it's such a bad thing.

This is just a little tip for those of you who dislike their xhtml to end up as tag soup and still prefer to send out Html 4.01 strict. Here is how to make all helper functions in Cake 1.2 output Html 4.01 compliant markup instead of xhtml.

The helper he's created just loops through the entire $tags array and does a replace on the greater-than sign to add a slash to make it compliant.

Considering the "big four" dynamic, procedural languages; Perl, Python, PHP and Ruby, to an extent they're much of a muchness, offering only small variations on the same theme (ignoring PHP's lack of support for functional-style programming). But sometimes little things make a big difference, and perhaps most of all when your code is given input to handle which it wasn't designed for. Knocked up a simple example to compare them in this area...

He compares four languages - Perl, PHP, Ruby, and Python - by giving, for each, code examples and what the output would be, including what would error out. These examples help to illustrate his final points:

• where is the point when a fatal error should be raised?
• what is it the languages should actually complain about?