The Stitcher.io blog has a new post from author Brentd sharing some thoughts about what PHP could be if "that one feature" were added. For him it would be a true strong typing system that didn't require workarounds to make happen.

Have you ever wondered how your life as a PHP developer would be different if that one feature you want was added? I've made the thought experiment quite a few times already, and came to surprising conclusions.

Let's take, for example, the debate about strong types in PHP. A lot of people, including myself, would like a better type system. Strong types in PHP would definitely have an impact on my daily work. Not just strong types, I also want generics, better variance and variable types. Improvements to PHP's type system in general would have quite the impact on my programming life.

So what's stopping us from reaching a solution?

He covers a few different topics in his discussion of the feature including issues around common vocabulary and the use of the feature (in this case type enforcement). He finishes the post talking about the impact a feature like this could have on PHP and some of the benefits that could come with a strongly typed version of the language.

Matthieu Cneude has written up a post for his site that shares some of his thoughts around what you shouldn't do with type hints in your code.

When PHP 7 came up with strong types, I saw the light. I had the hope not to see anymore bugs and inconsistencies due to weak typing in PHP. I remember reading some code and having no idea what could be the type of the variables I had in front of me.

[...] Strict types are big help as well as return type hint. You know what is the data you're manipulating. You don't have to guess anymore. However, PHP 7 wasn't the end of my typing struggle. You can still add a lot of ambiguity even if apparently PHP 7 tried to fix the problem. You still need to follow a couple of rules to keep your code consistently typed.

He then goes through some examples of weird results with some return type hints and unexpected results. He then moves on to strict type mode and how it can help resolve some of the oddities he discovered with just return type hints. The article spends the remainder of the time talking about the nullable type hint and some of the other "fun" surprises that can come from its use too.

On the SitePoint PHP blog there's a new post from Bert Ramakers showing you how to create strictly typed arrays and collections in PHP.

One of the language features announced back in PHP 5.6 was the addition of the ... token to denote that a function or method accepts a variable length of arguments.

Something I rarely see mentioned is that it’s possible to combine this feature with type hints to essentially create typed arrays.

He starts with an example of a class/method that only takes in a certain type of objects as a collection (using the "...") with a fatal thrown if anything else is given. He also shows how to do the same thing with scalar types and the "..." operator with a typed input. He does point out one problem with this approach, namely that if more complex input is required the single type just wouldn't work. His solution involves custom collection classes where the settings are in the collection and not passed directly into the method. This collection then contains some of the base functionality (like getting an average value from a set of floats) and can be enhanced with other typical interfaces to work like any other collection. He also presents another option: using value objects for validation of the input.

On thePHP.cc blog today there's a new post sharing some helpful hints related to refactoring your application to PHP 7 written up by a friend of the group, Tim Bezhashvyly.

Recently I have migrated a relatively large codebase from PHP 5.6 to PHP 7 and would like to share some of my learnings. To get the most out of this article, you should be familiar with scalar type declarations (and return type declarations). To learn about these and other features of PHP 7, I recommend the "PHP 7 Explained" eBook.

He makes the recommendation of a bold first step: enabling the strict typing on every file in your application to enforce the typing of all values. Next he recommends running your current test suite to see where the failures are. Changes are pretty high that you'll find issues with type switching and magic method handling. He suggests a method for migrating your code effectively to PHP 7: a test-driven migration. This focus works fine if your coverage is good but unless you're exercising all parts of your codebase things will unfortunately be missed.

He also points out some other changes you can make with this update including the removal of some PHPDoc annotations (you'll know the type for sure now) and modifications that may need to be made to current mock objects in your tests. There's a few other smaller things he recommends looking out for as well including the use of the "silencer" operator and exception changes.

In a new post to his site Matt Stauffer revisits the topic of "strict" mode with MySQL and Laravel with some customizations you can make around how your application uses it.

If you remember my post How To Disable MySQL Strict Mode on Laravel Forge (Ubuntu), you'll remember that MySQL 5.7 introduced something we've been casually calling "strict mode," which is really a combination of new modes that, in sum, make MySQL process your queries a little more strictly than before.

In my previous post I showed how to disable it on Ubuntu, but since then, Adam Wathan has added a feature to Laravel that allows you to define whether you're using "strict" mode and also allows you to customize exactly which modes you'd like enabled--all in code.

He briefly goes back over what the "strict" in "strict mode" means for your database and application, including a list of the set of modes it contains (essentially a grouping of modes). He then shows how to use the new feature to enable/disable it in a Laravel (5.2+) application through the database configuration. You can also get more in-depth and enable/disable individual modes that the "strict" mode contains if you need a bit more custom handling.

In a new post to his site Aaron Saray has shared two tips that can help you protect the information in your PHP sessions - two configuration options to enable that can enforce stricter standards and options enhancing their overall security.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

The two configuration options he mentions are ones that:

• force the session identifier to use cookies (versus also allowing it from the URL)
• enforce "strict mode" on the sessions

Each comes with a bit of description as to what the setting does and the recommended setting is to provide the most protection. One note, though: strict mode is only included in PHP 5.5.2 or greater.

Evert Pot has shared the results of a poll he recently set up on Twitter asking PHP developers if they planned to make use of the strict typing functionality in PHP 7 in their applications. Unsurprisingly, the majority voted that they will with a more undecided audience coming in second.

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. [...] So I was curious about everyone and whether you will be using strict mode or not. Results are in.

According to those that voted 46% were completely in favor of using the declare statement to enable strict typing in their PHP 7 code by default. The next group, the "undecided" were at 26% with "no way" and "what is that?" coming in farther down the list. He also mentions a package that's in the works from Justin Martin that would automatically add the declare statement to your code in the desired location(s). Additionally there's an extension in development from Joe Watkins that will do the same thing but making it a bit more automatic.

The Zend Developer Zone has posted the second part of their series (from community member Larry Garfield) about scalar types in PHP 7, one of many features in this "coming soon" release. You can find part one of the series here.

In our last installment, we talked about the benefits of more robust variable typing in PHP 7, and specifically the new support for typed return values. That is already a big boon to the maintainability of our code, but PHP 7 goes a step further. So far, we’ve only talked about typing against classes and interfaces. We’ve been able to type against those (and arrays) for years. PHP 7, however, adds the ability to type against scalar values too, such as int, string, and float.

But wait. In PHP, most primitives are interchangeable. [...] Much the same as return types, scalar types offer greater clarity within the language as well as the ability to catch more bugs earlier. That, in turn, can help encourage more robust code in the first place, which benefits everybody.

He starts by looking at the four new types that have been added in PHP 7: int, float, string, and bool. He includes a code example showing each of them in use on class interfaces and functions. He steps through the code example, explaining how the return type checking is handled for each instance. He also talks about how return type hinting can also benefit static analysis tools, allowing them to potentially find bugs in return values easier than before. Finally he covers strict mode, the method for enforcing types in your code and preventing PHP from doing any "magic" type switching for you. He also includes a code example of this functionality and how, with it enabled, it would have caught an error in his example on a integer vs string input.

In this new article Er Galvao Abbott talks about the struggle (and finally, inclusion) of type hinting in PHP, more specifically coming in PHP7, and how strict they can be.

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”. [...] 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.

He talks some about the background of the want and need for strict typing in PHP and mentions three RFCs that will influence the type hints and handling in PHP7:

• Scalar Type Hints v5— (forked) RFC by Anthony Ferrara on Andrea Faulds’ original
• Return Type Declarations —RFC by Levi Morrison
• Exceptions in the engine— RFC by Nikita Popov

He summarizes each RFC and what it contributes to the language. He ends the post by dispelling one thing about all of this new typing functionality - PHP will remain loosely typed, this new functionality is in a "strict mode" only used when specified.

Samantha Quinones has a new post today about something that has been known to trip up both new and experienced PHP developers - PHP's dynamic type juggling.

No matter how popular an activity it is, I really don’t like to bash on PHP. Every language has its flaws when you look closely enough, and if PHP wears its idiosyncrasies a little closer to the surface than most, I think it makes up for it in other ways. PHP’s handling of types, however, is confusing at best and at worst completely deranged.

She goes on to talk about the issues with type comparisons and how much trouble using the "==" (double equals) versus the "===" (triple equals) can potentially cause. While it's easier for new PHP developers to get caught by this issue, even experienced devs might miss it. She gives an example of a time in her own development involving the comparison of strings against constants and in_array's non-string type comparisons.