Tomas Votruba has a new post to his site showing you how you can get typed properties in your code "in a few seconds", a feature coming in the next major version of the language, PHP 7.4.

PHP 5.6 and 7.0 is going to be dangerous since 2019, PHP 7.1 is new baseline and PHP 7.3 is just about to be released in the end of 2018.

Is this the best time to upgrade your code to PHP 7.4?

He starts off by talking about the use of the @var annotation (DocBlock format) and how, while they can be informative, do nothing functionally speaking. He shows how to shift this over to a typed property, forcing the value to be an integer. He also covers current use of "best practices" when it comes to typing properties and how to think about future compatibility. He ends the post with the command you'd need to use - making use of the rector reformatter - to shift all of those @var annotations over to actual typed properties.

On the Laravel News site, there's a post talking about a feature that's coming in PHP 7.4: typed properties. It covers some of the basics of what they are and how they can help improve your code.

The Typed Properties 2.0 RFC was accepted with a vote of 70 in favor and one no vote. A 2/3 majority is required because typed properties is a language change. The typed property change is a PHP 7.4 proposal.

The post quotes the purpose of the feature from the RFC and provides an example of how most developers ensure property type safety now: via getters and setters. They then show a refactored version of this with typed properties, making for a much shorter class definition. They also include a code snippet showing all of the possible types you can use with the typed property functionality. They finish the post with a few of their own thoughts about string typing versus weak typing in PHP and link to the pull request that's in progress to implement the feature.

The SitePoint PHP blog has posted another in its series looking at Drupal 8 functionality today. In this latest post author Daniel Sipos looks at entity validation and typed data and what functionality the project provides over what was offered in previous versions (built on top of the Symfony validation component).

Data validation is a very important part of any application. Drupal 7 has a great Form API that can handle complex validation of submitted data, which can then be turned into entities. However, form level validation is problematic. [...] With the introduction of subsystems such as the REST API, Drupal 8 needed something better to handle this problem. [...] In this article, and its followup, we will explore the Drupal 8 Entity Validation API, see how it works, and how it can be extended.

He starts by looking at typed data and the consistency it provides in working with the metadata on objects. He includes a few examples of defining a string data type with a maximum length. He then applies this to content entities and enforcing the constraints provided by the types. In the next part of this series he'll look at the validation itself and how it works with these types/constraints.

On thePHP.cc site there's an article posted from Tim Bezhashvyly, a software engineer in Berlin, looking at typed arrays in PHP and how they (sort of) exist.

Even though Rasmus Lerdorf denies the fact, typed arrays exist in PHP. At least to some degree. This wonderful feature sneaked in as a side-effect of variadic functions that were added to the language in PHP 5.6.

[...] An array comprising the full argument list can be obtained using the func_get_args() function. [...] Regardless how many arguments have been passed to the function above, they are all accessible as elements of the ?$args array. This is nothing special really, until you realize that variadics can be augmented with type declarations.

Using these type declarations, you can, in essence create "typed arrays" where you know the end result will only be a set of objects of the defined type. The same goes for scalar type handling in PHP 7, making it so you can use things like "string" or "int" as your type enforcement. He does point out two issues in using this method however: the limit PHP places on the number of variadics in the function definition and that using functions to enforce types could result in a fatal error.

Wes Shell has posted a "PHP quicky" to his blog today looking at something at the core of the PHP language - its loosely-typed nature.

A loosely typed language such as PHP is a language that does not require you to declare a variable type when declaring a variable. What does that mean? In PHP when you declare a variable, you can with no need to worry about what kind of data will be stored in that variable.

He compares it to some of the other strictly-typed languages where the variable must be set up and cast to the type and the flexibility that having looser types can have over it. He also looks at some of the drawbacks (ex. can lead to bad code) and advantages (ex. highly dynamic, flexible applications) of this method.

David Coallier has posted a nice overview of what SPL Types are in PHP and a brief example of hos they can be used.

I got karma to SPL_Types and added a new SplFloat() object, a few warning typos and more "flexible" strict modes for different types.

SPL_Types are a way to make PHP strongly typed (no adapting variables) to help make a PHP application "more correct" by forcing the variable's type to stay the same. His example shows the creation of a few variables with these new methods and how they can be used, both correctly and incorrectly.

David Coallier has posted a nice overview of what SPL Types are in PHP and a brief example of hos they can be used.

I got karma to SPL_Types and added a new SplFloat() object, a few warning typos and more "flexible" strict modes for different types.

SPL_Types are a way to make PHP strongly typed (no adapting variables) to help make a PHP application "more correct" by forcing the variable's type to stay the same. His example shows the creation of a few variables with these new methods and how they can be used, both correctly and incorrectly.