One of the most annoying behavior of PHP type hinting feature is triggering error instead of throwing exception when instance type is invalid.

By default, a failure generates a "catchable error" that, thanks to the custom error handling methods PHP includes, can be correctly handled. He includes a snippet of code that defines the errorHandler method that checks the error type for E_RECOVERABLE_ERROR and throws the exception (an ErrorException) if found.

A small gotcha I recently ran into: If you use typehinting, PHP never checks that the class your typehint specifies actually exists!

He includes simple examples that define the class type hint as some random string and PHP never throws an error for it. He also notes that it's even worse when dealing with namespaces - how it handles exceptions locally unless you specify otherwise. Of course, these "features" can be put to good use in the right situations, but they can be confusing for a developer without a keen eye.

You may be wondering why you would want type hinting in a dynamic language. This can come in very handy especially if you are looking to enforce a specific type or need to ensure that you are indeed working with say an integer. Since this is written in C, it will be far faster than actually type casting it yourself or enforcing it yourself. General speed improvements are always nice to have.

He includes two code examples of it in use and points to the php.internals mailing list for the vote count either way. So far (as of the time of those post) the results seem mixed with some recommending it outright while others suggest waiting until the spec is completely done before integration (PHP6?).

There has been a lot of comments both on this blog and the internals list. There seems to be a fairly large group of core developers who like the idea as well as surpassingly large support base on the user level too (wow, didn't think that this many people want type hinting).

Despite some of the nay-sayers who don't think it's a good idea, the majority seems to approve and work has already been done on a new patch you can apply to your systems. He includes the Changelog information as well as links to the patch (txt) and a test suite (bz2).

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.

Historically, PHP has been developed following the scratch-an-itch method [...]. This development process makes for some haphazard functionality, and has, in the past, been the source of many annoyances that need to be handled with extreme care.

He does mention some of the good things that have come out of this process like OOP in PHP4, SimpleXML functionality and type hinting but warns that if things swing too much the other way (planning out everything, only adding things by committee) that PHP might swerve towards a dangerous precedent - the Java community's mentality.

The problem isn't that namespaces are bad, it's that these arcane structures seem to have so little impact on development in PHP today for many many people. Does that mean it's unimportant?

He talks about the real value of namespaces, a comparison to type hinting's inclusion, the current amount of (needless?) traffic on the php.internals list and his opinions on why namespaces are valid.