A little while back Matthew Turland posted about something that some developers moving over to PHP from more strict languages have an issue with - variable typing - and how its evolved in languages over time.

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.

In a new post today, Clay Loveless talks about some issues he's been having with PHP and JSON, specifically with the JSON encoding method in PHP 5.2.1.

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.

Felix Geisendorfer has a "quick hit" tip posted to his blog today on using HTML 4.0.1 in your CakePHP 1.2 installation.

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.

Harry Fuecks wonders in this new post on the SitePoint PHP Blog "how strict is your dynamic language?"

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?