In a nutshell, this means that PHP 5.3.99 introduces new syntax -- scalar type hints -- but no new semantics. The latter can either be implemented as an extension written in C/C++, in userland PHP code, or in a tool that statically analyzes the code.

He includes an example fro userland with a "php_check_parameters" function that looks at the arguments of the current method and uses Reflection to check against the type hints for the correct value type.

So PHP 5.3 has lots of new stuff offer, so let's take a look at one change: Added long-option feature to getopt() and made getopt() available also on win32 systems by adding a common getopt implementation into core. (David Soria Parra, Jani)

This gives Windows users a function they haven't had before in both web-based applications and on the command line. You can get more information about the use of the function from its page in the manual.

I stumbled across a blog post on how to implement Enums in PHP via userland code written by Jonathan Hohle. I liked the concept he had, but the implementation was a bit unappealing because it used eval() among other more minor issues. You shouldn't need to generate Enums at runtime, so I took that as a challenge to find a way to do it at compile time, thus making the code much more efficient.

His enums would support type hinting and would, ideally, be iterable. He gives the code he's worked up - a base class, another than extends it to make a basic enum structure and some handy changes to support comparisons. A few more changes (and a few other extended classes later) he has some pretty well functioning enums that can even bee iterated through.

Most compiled languages that I have used have some kind of container implementation, Lists, Maps, Trees, Stacks and all their many variations. PHP has arrays and the SPL.

The only problem he's noted so far is that containers made in userland would be slower than ones created natively. A comment from Antony Dovgal points out a project similar to what he's looking for that's already in the works.

So now we finally have some guidelines on how users should name their identifiers to be fairly future proof. This should hopefully help reduce the amount of pain people suffer when PHP adds new features like a class for Date or File handling. Although the two mentioned examples have settled on using DateTime and FileObject to get around the issue at least partially.

The guide itself is unfortunately spread over 3 pages, which does not seem to make sense since there is really not that much content there yet. Then again the guide may get expanded in the future. Anyways I recommend that every serious PHP programmer have a look at the guide. If there are any issues please let me (or the PHPDoc team) know. Otherwise make sure you adapt your internal CS to match this guide.

The guide talks about the naming of items in the global namespace (functions, classes, interfaces, etC), some rules to follow for internal identifiers, and some quick tips on naming to create pseudo-namespaces.

I suppose I'm fixated on objects, but damn it, they are awesome. Recently, I've been thinking of creating a framework that takes array and file functions and creates a class wrapper around them. It would have been nice if PHP offered an object for handling Arrays and Files. SPL does manage some sorting for arrays, but I would like to fully manage arrays through the internal Array methods.

He dives deeper into the Array objects, looking at how to use them, appending them to each other, how much overhead making the object causes (testing), and the results of those tests.