A few weeks later (my inbox is a black hole and it takes a while to process these things) I fell over a throwaway comment to an undocumented constant JSON_NUMERIC_CHECK, and I added the constant name to my todo list. In the time it took for me to actually get around to googling for this, some wonderful person updated the PHP manual page (this is why I love PHP) to include it as a documented option, and someone else had added a user contributed note about using it.

This option, JSON_NUMERIC_CHECK, tells the json_encode function to property consider numbers in its encoding process. It applies globally, so if there's an instance where you don't want something assigned as a number, you might need to go with another, more flexible JSON encoding option. You can find information about this and other possible options json_encode can take on its manual page.

As long as you make sure you always use strict checking (=== and !==) where you can, and fall back to the loose checks when you must. As a PHP developer, I think it's very important to understand and memorize exactly how these work, whether you're writing new code, or maintaining existing code.

He points out a specific example of some code that seems counter-intuitive when you compare how it reads and how it actually works (strings converted to floats and evaluated)

The moral is: always do strict checks when you are able to.

On a general level most people agree it would be a good idea to have, since it is an optional feature and does not introduce any regressions, heck you can even mix type hinted code with the non-type hinted one. The "PROBLEM" has always been combining of PHP's typeless nature with type hinting, which is where the consensus has been difficult (impossible) to reach.

He mentions an example of why its such an issue (technically, both 1 and "1" are valid numbers) and includes a link to a patch that gives a new hint to help with the problem.

Nice URLs, readable URLs, search-engine-friendly URLs. Different names same deal. [...] Turns out this isn't all that hard with PHP - in fact it can turn into something that's very useful from more than just a readability viewpoint.

He shows how to use mod_rewrite and an .htaccess file to automatically grab the request and map it to the right place. Then, the PHP script looks at the incoming data and pushes the correct page back out to the browser. He's also included some modifications to the original idea that allow for numeric grouping and named groups for rewriting content.

In our last exciting adventure (back in early November), we braved crocodiles, ravenous editors, most of the PHP statements, and beginning loops. In this edition we'll cover the final statement, the Switch, and discuss arrays. So sit back, order your R2D2 robot to bring you a cold, frosty Jolt Cola, and let's get cracking.

They start with a simple example of a switch statement (to echo out strings) and follow it with a detailed description of the different sorts of arrays - numeric indexed, associative and multidimensional versions.

Summarizing, the factory pattern can be really useful when it comes to creating multiple objects that belong to the same family. In this three-part series I'm going to take a close look at it, and also demonstrate its remarkable functionality by showing you a decent variety of code samples, so you can start quickly including this pattern into your own PHP applications.

They lay the foundation by creating some basic factory classes for working with numeric and associative arrays. On top of this, they create the processing classes to create things like uppercase numeric arrays and lowercase associative arrays. Finally, they give examples of how to put it to use making several different sorts of arrays, including their output.