Attributes are awesome

Especially in combination with constructor property promotion.

Recently I did a code-review on an entity from a PHP8.0 project. What I saw was this:

The origin

<?php

declare(strict_types=1);

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
#[ORM\Table(name: 'user')]
class User
{
    #[ORM\Id]
    #[ORM\Column(type: 'integer', unique: true)]
    public int $id;

    #[ORM\Column(type: 'string')]
    public string $username;

    #[ORM\Column(type: 'string')]
    public string $passwordhash;

    public function __construct(
        int $id,
        string $username,
        string $passwordhash,
    ) {
        $this->id = $id;
        $this->username = $username;
        $this->passwordhash = $passwordhash;
    }
}

I was thinking about using constructor property promotion to get rid of the property declaration and property assignment but immediately thought that that would require us to handle the attributes differently. So I shortly checked my favourite search engine and realized that indeed we are able to shorten this whole stuff considerably:

The result

<?php


declare(strict_types=1);

namespace App\Entity;

use Doctrine\ORM\Mapping as ORM;

#[ORM\Entity]
#[ORM\Table(name: 'user')]
class User
{
    public function __construct(
        #[ORM\Id]
        #[ORM\Column(type: 'integer', unique: true)]
        public int $id,
        #[ORM\Column(type: 'string')]
        public string $username,
        #[ORM\Column(type: 'string')]
        public string $passwordhash,
    ) {}
}

Combining the attributes with the constructor property promotion allows much smaller entity definitions.

Immutability

In our case we also cleared a misunderstanding. My colleague was under the impression that Doctrine requires properties to be public. Otherwise they are not able to be hydrated properly. That is not the case and Doctrine can perfectly hydrate private properties!

So we decided to go for private properties in combination with getters. As in our concrete implementation we actually also need to execute some logic before returning some of the values. So declaring the properties private and having getters provides us with a truly immutable entity.

As we are not using PHP8.1 yet we could not make use of the new readonly declaration which would have solved the issue with the immutability though as we need logic in some cases the approach with using getters always makes more sense in this particular setup.

Enums. With PHP < 8.1

Recently I had to build something where an Enum would have been perfect.

But…

The Challenge

It needed to run on PHP 8.0. Of course.

So what to do? I decided to build an Enum like thingy that I can easily upgrade into a real Enum once we are on PHP8.1 with that project.

Why not use a library for that? There are plenty of libraries on packagist that already provide you with the basics!

For one thing: I only needed one Enum. Not a multitude. And Adding a further dependency to make creating one enum easier that will (hopefully) converted into a “eral” enum in about half a year? That sounds bit like taking the sledgehammer to crack a nut.

And on the other hand it turned out that creating an enum from scratch isn’t rocket science.

Continue reading Enums. With PHP < 8.1

On deprecating dynamic properties

Yesterday the RFC regarding Deprecating Dynamic Properties went into voting phase and it currently looks like the overwhelming majority supports the RFC.

But nevertheless the discussions yesterday started in the wider PHP community whether that is a good idea or not.

To summarize the RFC in very short terms: Currently PHP allows to assign values to a class property that was not previously declared. The RFC proposes to remove this implicit feature in PHP9. It will still be available as an explicit feature when the creator of the class adds an Annotation [AllowDynamicProperties] on the class level.

To prepare for that, in the next minor version of PHP – PHP 8.2 – whenever one assigns a value to an undeclared property there will be a deprecation notice raised.

So the proposal is – in essence – about moving from implicitness to explicitness. Which is in my opinion a very good move.

So what is the discussion that I was talking about previously all about? After all that sounds like a good move, doesn’t it?

Continue reading On deprecating dynamic properties

Transliter… what?

Every now and then I am challenged with modifying Unicode-strings. Whether by converting from any non-ASCII script to ASCII or handling differently normalized strings, all of these actions are called “Transliteration”

I first encountered that when I built an application that create PDF-Files on a Linux-Server that would then be overwritten from an application running on a mac that had the folder mounted via CIFS. Everything was working great. Until one of the people thought it would be a great idea to enter a filename with a german Umlaut. So the application created the file “example_ä.pdf” on the server. After some time we realized that there was a second file in that folder with the name “example_ä.pdf”.

Wait!

What?

Continue reading Transliter… what?