PHP7: More strict! (but only if you want it to be)

Er Galvao Abbott
The White Hat ElePHPant
3 min readMar 18, 2015

It wasn’t easy (we knew it wouldn’t be) and certainly wasn’t pretty (we sort of knew that as well), but it’s finally official: PHP7 will come with Scalar Type Hints (STH) and an optional “strict mode”.

Background, or “Let’s talk about typing, shall we?”

PHP, as you may well know, is a dynamically[1] typed language, and it has been that way since it’s conception.

As with many PHP characteristics, this fact has been used to criticize it over and over again. What most people don’t get, though, is that there are plenty of other language examples out there which explicitly decided to use dynamic typing[2], including (but not limited to): Perl, Ruby, Javascript, Objective-C and so on.

Oddly enough, you don’t see people trashing those around, do you?

I’ve never had any issues with dynamic typing. In fact, I’ve explained many times to my students that, although one could surely argue that programming with such a language could be considerably more difficult — since you may “chaotically” change types… well, pretty much anywhere — it would be very wrong, IMNSHO[3], to state that dynamic typing leads to bad code.

As often happens with PHP detractors[4] criticism is either taken out of context, incomplete or outdated. This is not different when it comes to types.

For an example, PHP has, and had for a very long time, a number of ways of dealing with types, so even if you’re still able to change them, you can ensure a specific type is being used at a specific point (is_type() functions, [set|get]type(), and so on).

Even type hinting has been used for quite a while although, one might say, in an “incomplete” way: you can make functions/methods accept only arrays or instances of specific objects as parameters.

Game Changers, or “So, what’s new?”

There are basically three RFCs that were accepted for PHP’s next major, PHP7:

Scalar Type Hints v5[5] — (forked) RFC by Anthony Ferrara on Andrea Faulds’ original

PHP7 will come with Scalar Type Hints, namely int, float, string and bool. These will allow us to better hint on function/method parameters and return values (see the next one). Also, this won’t only apply to user-defined functions but to native functions as well.

Additionally, we’ll be able to declare a per-file strict mode, which will make PHP raise an exception (see the third RFC below) when an incoherent type is passed to functions/methods.

Return Type Declarations[6] —RFC by Levi Morrison

This will allow us to hint on return types for functions/methods, giving us better control of what is returned and an easier way to detect incoherent behavior.

Exceptions in the engine[7] — RFC by Nikita Popov

As of now using incorrect types — for the aforementioned array and object hints— will result in a (catchable) fatal error. As a result of this RFC being accepted, as of PHP7 this behaviour will result in an (Engine) Exception, making it easy to detect type hinting related problems and allowing us to react properly or even do a more graceful exit on these cases.

The Common Misconception or
“WOW! PHP WILL BE STRICTLY TYPED!!!”

NO, IT WON’T!

This is basically a step towards a more strict way of coding in PHP. Will we see more steps in that direction in the future? We don’t know and we’re OK with that for now.

What’s brilliant about the body of work represented by these RFCs is that by implementing their concepts and specially making the “strict mode” optional the choice of being more strict remains with the programmer.

This way it provides some measurement of strictness while respecting the fact that PHP is, and — AFAWK — will always be a dynamically typed language.

Don’t wanna use it? You think this sucks? Well, carry on, don’t use it. It’s simple like that.

Wrapping up, or… Wrapping up!

PHP7 will be a fantastic new major for PHP. Along with other already decided features (see Phil Sturgeon’s post[8] for more information), the introduction of STH and the optional strict mode represent exciting new possibilities for the language.

All of this combined will take PHP to a whole new level, keeping the language relevant and exciting, and showing everyone else that we’re not afraid of growing.

Long live PHP!

Footnotes and References

[1] I personally prefer “strictly” and “dynamically” rather than “strongly” and “weakly” because the latter implies that there’s something inherently wrong with dynamic typed languages.
[2] http://en.wikipedia.org/wiki/Category:Dynamically_typed_programming_languages
[3] In My Not So Humble Opinion
[4] Yes, they’re so common they are a “thing” now =P
[5] https://wiki.php.net/rfc/scalar_type_hints_v5
[6] https://wiki.php.net/rfc/return_types
[7] https://wiki.php.net/rfc/engine_exceptions_for_php7
[8] https://philsturgeon.uk/php/2015/03/15/php-7-feature-freeze/

--

--

Er Galvao Abbott
The White Hat ElePHPant

Brazilian programmer and web app security advisor; Zend Framework Evangelist.