PHP5.x or PHP6 – Argument for Type-Hinting: Better IDEs

I’ve read some posting lately about PHP6, the Meeting Notes by the Developers, etc. that deal with type-hinting, especially scalar type hinting. Here is my reasoning why PHP should allow for more type-hinting scenarios: it allows IDEs to be more powerful. An example would be auto completion. Many times an IDE can’t possibly know what is being returned by a function or what is stored a variable because PHP is not strongly typed.

An example from another language is ASP .NET. It is strongly typed, which means there is almost zero guess work what is stored inside variables or what is returned by functions. The reason why I think .NET is so popular is that Visual Studio is so powerful. It’s features with auto-completion and refactoring are incredible.

However, being strongly typed can have heavy disadvantages for many developers. Some things that are easy to do in PHP that can be very complex in ASP .NET. This is why I prefer PHP over ASP .NET.

Some IDEs like Zend Studio Neon try to accomplish many auto-complete and refactoring abilities by enforcing strict include patterns and Doc Blocks. This can be more restricting and cumbersome than many restrictions enforced by strongly typed languages while still failing to provide really good features that VS.NET has.

So this is why I am pro PHP having a very complete set of type-hinting instead of being strongly typed. This allows for the flexibility that PHP provides, but also allow developers to integrate good-practices by using type-hinting in many scenarios, not just in function parameters.

A real life example is trying to use a class within a View Script (i.e. myview.phtml) that was set to a Zend_View by the Zend_Controller_Actio:

Setting the Variable:

[php]
function myAction()
{
$object = new MyClass();
$this->view->object = $object;
}
[/php]

Now, my inside that file while I edit Zend Studio Neon can know $object is an instance of MyClass, so it can auto-complete all of the members and methods of that class.

However, inside my View Script:

[php]
$object = $this->object;
echo $object->myFunction();
[/php]

My IDE has no way of knowing what $object is, because while editing it can’t know this file will be included by a Zend_View class, and because $object set dynamically at run time my IDE can’t know $object is an instance of MyClass. Lets say I’m going to use $object’s members and methods over 50 times in this file. It would save me a lot of time from only having to type so much and having auto complete finish my entries, as well as help prevent typos. Even if a typo slipped in, I’d hope PHP during run time would throw an error, like an E_STRICT, and continue to run. This would allow for best-practice coding that would help prevent errors.

Example of what I’d want:

[php]
$object = <MyClass>$this->object;
echo $object->MyFunction();
[/php]

Now the IDE could know “Oh, this is a MyClass, I’ll make his life easy and enable auto-complete and refactoring”.

Some may say this is frivolous and I’m not preaching the “PHP Way”. After all, the developer’s decided that type hinting isn’t the “developer’s” way. I’m already forced to use DocBlocks to declare what members store and what methods return so Zend Studio can predict what to auto-complete. Adding more DocBlocks to support type hinting anywhere does not help.

The ultimate goal in my mind is to help PHP be more corporate friendly. My current company doesn’t want to invest in developing PHP applications because there are no good tools to help code in PHP. Its just scripts. Of course this isn’t the only reason, but in my experience the more large and advanced a project becomes, the less PHP is apt to help solve problems large projects face. If I have a large project with 10 programmers, I’ve found myself reading other’s code to make sure I know what is what instead of having my IDE help me out.

Hopefully Type-Hinting will eventually be embraced by PHP.