{"id":2381,"date":"2018-10-28T10:07:07","date_gmt":"2018-10-28T09:07:07","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=2381"},"modified":"2019-08-20T03:35:41","modified_gmt":"2019-08-20T02:35:41","slug":"php-typed-properties","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2018\/10\/28\/php-typed-properties\/","title":{"rendered":"PHP Typed Properties"},"content":{"rendered":"

\"\"Lately there has been a lot of hype around the typed properties that PHP 7.4 will bring. In this post I outline why typed properties are not as big of a game changer as some people seem to think and how they can lead to shitty code. I start by a short introduction to what typed properties are.<\/p>\n

What Are Typed Properties<\/h3>\n

As of version 7.3, PHP supports types for function parameters<\/a> and for function return values. Over the latest years many additions to PHP types where made, such as primitive (scalar) types<\/a> like string<\/code> and int<\/code> (PHP 7.0), return types<\/a> (PHP 7.0), nullable types<\/a> (PHP 7.1) and parameter type widening<\/a> (PHP 7.2). The introduction of typed properties<\/a> (PHP 7.4) is thus a natural progression.<\/p>\n

Typed properties work as follows:<\/p>\n

class User {\n    public int $id;\n    public string $name;\n \n    public function __construct(int $id, string $name) {\n        $this->id = $id;\n        $this->name = $name;\n    }\n}<\/pre>\n
You can do in two simple lines what takes a lot more boilerplate in PHP 7.3 or earlier. In these versions, if you want to have type safety, you need a getter and setter for each property.<\/p>\n
\u00a0   private $id;\n    private $name;\n\n    public function getId(): int {\n        return $this->id;\n    }\n    public function setId(int $id): void {\n        $this->id = $id;\n    }\n \n    public function getName(): string {\n        return $this->name;\n    }\n    public function setName(string $name): void {\n        $this->id = $name;\n    }<\/pre>\n
Not only is it a lot more work to write all of these getters and setters, it is also easy to make mistakes when not automatically generating the code with some tool.<\/p>\n
These advantages are what the hype is all about. People are saying it will save us from writing so much code. I think not, and I am afraid of the type of code those people will write using typed properties.<\/p>\n
Applicability of Typed Properties<\/h3>\n
Let’s look at some of different types of classes we have in a typical well designed OO codebase.<\/p>\n
Services are classes that allow doing something. Loggers are services, Repositories are services and LolcatPrinters are services. Services often need collaborators, which get injected via their constructor and stored in private fields. These collaborators are not visible from the outside. While services might have additional state, they normally do not have getters or setters. Typed properties thus do not save us from writing code when creating services and the added type safety they provide is negligible.<\/p>\n
Entities (DDD term) encapsulate both data and behavior. Normally their constructors take a bunch of values, typically in the form of Value Objects. The methods on entities provide ways to manipulate these values via actions that make sense in the domain language. There might be some getters, though setters are rare. Having getters and setters for most of the values in your entities is an anti-pattern. Again typed properties do not save us from writing code in most cases.<\/p>\n
Value Objects (DDD term) are immutable<\/a>. This means you can have getters but not setters. Once again typed properties are of no real help. What would be really helpful however is a first-class Value Object construct part of the PHP language<\/a>.<\/p>\n
Typed properties are only useful when you have public mutable state with no encapsulation<\/a>. (And in some cases where you assign to private fields after doing complicated things.) If you design your code well, you will have very little code that matches all of these criteria.<\/p>\n
Going to The Dark Side<\/h3>\n
By throwing immutability and encapsulation out of the window, you can often condense code using typed properties. This standard Value Object …<\/p>\n
class Name {\n    private $firstName;\n    private $lastName;\n \n    public function __construct(string $firstName, string $lastName) {\n        $this->firstName = $firstName;\n        $this->lastName = $lastName;\n    }\n \n    public function getFirstName(): string {\n        return $this->firstName;\n    }\n\n    public function getLastName(): string {\n        return $this->lastName;\n    }\n}<\/pre>\n
… becomes the much shorter<\/p>\n
class Name {\n    public string $firstName;\n    public string $lastName;\n \n    public function __construct(string $firstName, string $lastName) {\n        $this->firstName = $firstName;\n        $this->lastName = $lastName;\n    }\n}<\/pre>\n
The same goes for Services and Entities: by giving up on encapsulation and immutability, you gain the ability to not write a few lines of simple code.<\/p>\n
This trade-off might actually make sense if you are working on a small codebase on your own or with few people. It can also make sense if you create a throw away prototype that you then actually throw away. For codebases that are not small and are worked on by several people writing a few simple getters is a low price to pay for the advantages that encapsulation and immutability provide.<\/p>\n
Conclusion<\/h3>\n
Typed properties marginally help with type safety and in some rare cases can help reduce boilerplate code. In most cases typed properties do not reduce the amount of code needed unless you throw the valuable properties of immutability and encapsulation out of the window. Due to the hype I expect many junior programmers to do exactly that.<\/p>\n
See Also<\/h3>\n