Following up on his prior post showing how to convert DocBlock comments to official type hinting, Tomas Votruba has continued the series with a new post showing how to do the same thing but without previously defined DocBlocks.

In previous post we looked at how to migrate from docblocks to type declarations. From @param Type $param to Type $param. Even if it doesn't break code like coding standards do, works with inheritance, localized self and static and propagates types to all child classes, it's still not such a big deal.

But how do you complete type declarations if don't have any docblocks?

After a "gloom and doom" start to the post, he circles back around and shows how PHPStan and Reactor can help with static analysis. After providing several examples of how the refactor should look, he shows how to set up Reactor for both return types and the migration of properties to their correctly typed versions automatically.

In a post to his site Tomas Votruba takes a look at the "rocket science" behind the migration of DocBlocks to typehints in your PHP application.

What if you could add scalar typehints int, bool, string, null to all parameter type and return type by running a CLI command? But also all classes, parent, self and $this?

Do you think it's an easy task to move @param int $number to (int $number)?

He talks about some of the current tools that handle the conversion of type-hints to type checks, but points out that some of them break the code (as they don't have the right context). He shares the results of some of his own research using these tools and issues that can come up with code changes. He also includes issues that could come up with the use of self/parent and namespacing. The post ends with some instructions on using the rector/rector package to handle this refactoring in a bit better way (including the configuration required).

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.

Ruslan Karimov has written up a post for the 4xxi.com blog covering the use of custom types with Symfony and Doctrine to implement features specific to your database of choice.

ORMs are great. In theory, they insure you against potential changes in your RDBMS and offer an easy plug’n’play solution for integration your domain code with database. In practice, however, since ORMs have to be compatible with all major vendors, their possibilities are often limited. Perks and tricks of specific RDBMS are left out.

One of such perks is so-called range types in PostgreSQL. There are plenty of cases when range types are applicable, but people (in my experience) often stick to old solution with two separate DATETIME columns. Last time I asked a fellow developer about the reason behind it and they said: ‘I use Doctrine in my project, and Doctrine does not support it’. So here we are.

He starts with a brief introduction to a custom type in Doctrine and a ranged type in PostgreSQL. He then shows how to create a custom "DateReangeType" to work with the ranged types and how add it to your Symfony configuration as a custom type. He ends the post with an example of it in use in an entity and in the client code making the database request. Full code can be found in this Github repository.

In a new post to his site Thijs Feryn has shared an overview of the different types of type errors that can pop up in PHP 7. This includes both a text-based and video based versions depending on your preference.

PHP 7 has a concept called Type Errors. These errors are thrown on a type mismatch when interacting with functions. They can be caught just like exceptions. I created a video that explains the situation. This blog post goes into more detail and has some code examples.

The post gets into the details of the type errors including topics like:

• new type hints that were introduced
• how you can manually throw type errors
• when PHP itself would throw the errors
• type coercion

There's also a brief section about strict typing and how that changes what errors PHP might throw in your scripts.

On the QaFoo blog they've posted an article that shares some of their thoughts on "when to abstract" in your code - essentially finding that point where abstracting out functionality makes sense.

One of the most difficult challenges in a developers life is finding the "right" abstraction, or at least the best one given the current circumstances. The core problem is that abstraction is a bet on the future development of the software and we know that future is volatile. The circumstances will change, so will the view on the best abstraction change.

But there is another dimension which influences this decision: What kind of software are you developing?

They start off by defining three different types of projects (internal, library and adaptable) and move into how this type changes when/how you abstract things in your code. They give a brief summary for each type and when it usually makes sense, including steps to take (concrete first, then abstract).

In his latest post Rob Allen shows a handy way, making use of the http://php.net/getimagesize function, to determine the image type of a file based on header information returned.

One thing I learnt recently which I probably should have known already is that getimagesize() returns more than just the width and height of the image. [...] However, getimagesize() also returns up to 5 more pieces of information. Interestingly, the data array is a mix of indexed elements and named elements

He gives an example of the output from the function and shows how, using data from the returned array, you can compare constants (IMAGETYPE_JPEG, IMAGETYPE_GIF, IMAGETYPE_PNG) to determine what the image type is. This is a better option than relying on the extension of the file as that can be easily faked.

Chris Fidao has a quick post to his site looking at content negotiation in Laravel apps using some of the framework's own built-in functionality.

Here's a little bit about content negotiation. An HTTP client, such as your browser, or perhaps jQuery's ajax method, can set an Accept header as part of an HTTP request. [...] This header is meant to tell the server what content types it is willing to accept.

He starts with a bit of illustration as to what the Accept header is and what kinds of values it supports (and how it looks as a HTTP header). He then shows how to check the Accept header value inside the current request. He also shows the "shortcut" Laravel provides to test if the Accept header specifically references JSON with the wantsJson method. He also mentions the accepts and prefers methods for checks that need to be a bit more in-depth.

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.