subscribe

Strict typing in PHP 7 - poll results

I maintain a number of PHP packages, and with the release of PHP 7, I’ve been starting to wonder when a good time is to switch.

It’s a hard decision, and I haven’t quite made one yet, but really the PHP 7 killer feature are it’s new argument type declarations and return type declarations.

Yes, there’s the speed thing too, and that’s a great reason to want to update to PHP 7, but it doesn’t force you to change the minimum required version.

The improved typing system will make all my sources a lot more robust, and and I expect to find a lot of hidden bugs by just implementing them.

But PHP wouldn’t be PHP if there wasn’t something odd about this feature. Type hinting comes in two flavors: strict and non-strict. This is the result of a long battle between two camps, a strict and non-strict camp, which in the end was resolved by this compromise.

Now by default PHP acts in non-strict mode, and if you’d like to opt-in to strict-mode, you’ll need to start every PHP file with this statement:

<?php declare(strict_types=1);

// Rest of your code here

?>

Note: The declare statement here doesn’t have to be on the same line as <?php, but I have a strong suspicion that this will be the leading declaration style.

So I was curious about everyone and whether you will be using strict mode or not. Results are in:

This definitely suggests that most people will want strict mode (and that perhaps it should have been the default). It also tells me that a lot of people are unfamiliar with the feature. If that’s you, I can recommend eeading the manual, but if anyone has a good blog resource that explains things in more detail, let me know!

The nice thing about how the different modes are implemented though, is that you don’t have to worry if one library uses strict mode and another is not.

Setting your source to strict mode influences only the caller. So ultimately using strict_mode only really has an effect on whoever wants to use it, and their own sources.

Some people are still clearly unhappy with this though.

Comments

Justin Martin is working on a PHP stream wrapper to automatically add declare upon including PHP files:

Joe Watkins is solving the same problem, but via a PHP extension:

On reddit, OndrejMirtes mentions:

Yes! We started adding that to the files in our codebase on the day we deployed PHP 7 to our servers and it already uncovered a lot of bugs and inconsistencies, most often passing different parameters than was intended to invoked functions and methods.

Drew McLellan is not so lucky:

Web mentions

Comments

  • Rasmus Schultz •

    Yep, that's pretty much the first thing I thought when I saw PHP 7 would be getting scalar type-hints and return type-hints.

    "Awesome!", I thought. "Finally I can move from those silly php-doc type-hints to actual type-hints, and things will actually get checked at run-time. PHP is turning into a gradually-typed language! Yay!"

    Not so much. I have thought for a while about how we can fix this, and actually, strict mode wasn't the first thing that brought it on - declaring the encoding was.

    How can we fix this? Stream wrappers seem like a hack and yet another work-around.

    I've got only one idea so far: add some kind of project root file, e.g. "php.json", something comparable to "composer.json" for Composer, or "tsconfig.json" for TypeScript - this would contain the declarations for files in that folder and all sub-folders. You could place it in your project root, check it in with your Composer package, etc.

    It's not perfect, but has some big advantages, and could even pave the way in the future for breaking changes to APIs (introducing long sought-after consistency in certain functions' argument lists) and possible even changes/improvements to PHP language syntax that require BC breaks.