Forem: Frédéric Bouchery

Chat : Test unitaire sur des méthodes privées

Frédéric Bouchery — Thu, 26 Oct 2023 15:11:48 +0000

(English translation: Chat: Unit test of private methods)
Je vous livre ici, l'échange que j'ai eu avec ChatGPT (version 4) au sujet des tests unitaires de méthodes privées, car je trouvais l'exercice intéressant.
Les mises en gras sont de mon fait à posteriori pour mettre un peu de relief.

Une phrase que je retiens et que j'aime beaucoup :

Le but des tests unitaires est de s'assurer que chaque partie de votre code fonctionne comme prévu, et non de s'assurer que chaque méthode passe un test.

Fred

Je souhaite mettre en place des tests unitaires avec PHPUnit. En PHP, que penses-tu des tests de méthodes privées ?

ChatGPT

Il est généralement recommandé de ne pas tester directement les méthodes privées dans PHPUnit. Les méthodes privées sont considérées comme des détails d'implémentation de la classe et ne devraient être testées qu'indirectement par le biais des méthodes publiques qui les utilisent.
Si vous ressentez le besoin de tester une méthode privée directement, cela pourrait indiquer un problème de conception. Peut-être que la classe fait trop de choses et qu'elle pourrait être refactorisée pour déplacer cette fonctionnalité vers une nouvelle classe où elle serait publique et pourrait être testée directement.
Cependant, si vous devez absolument tester une méthode privée pour une raison ou une autre, vous pouvez utiliser la réflexion en PHP pour rendre une méthode privée accessible et ensuite la tester. Mais encore une fois, cela devrait être l’exception plutôt que la règle dans la plupart des cas.

Fred

J'ai une partie du code avec du traitement algorithmique que j'aimerais bien valider, mais je ne souhaite pas qu'il soit accessible de l'extérieur. Si je plaçais ce code dans une classe à part, cela reviendrait à le rendre accessible, hors il n'a aucun intérêt en dehors du contexte de ma classe. Quant-aux tests uniquement des méthodes publiques, cela me force à mocker beaucoup de choses, et les tests deviennent complexes. En testant ma méthode privée, j'ai des tests très simples

ChatGPT

Dans ce cas, si vous pensez que tester vos méthodes privées directement vous apporte de la valeur et améliore la qualité de votre code, alors vous devriez le faire.
En fin de compte, l'objectif des tests unitaires est de s'assurer que votre code fait ce qu'il est censé faire et de vous aider à identifier et corriger les bugs. Si tester directement une méthode privée vous aide à atteindre ces objectifs, alors il n'y a pas de raison de ne pas le faire.
Comme mentionné précédemment, vous pouvez utiliser la réflexion pour accéder aux méthodes privées et les tester. Voici un exemple de comment vous pouvez faire cela en PHP :
$className = new YourClass();
$reflector = new ReflectionClass($className);
$method = $reflector->getMethod('yourPrivateMethod');
$method->setAccessible(true);
$result = $method->invokeArgs($className, [$arg1, $arg2]);
// maintenant vous pouvez faire des assertions sur $result
Cependant, cela peut rendre vos tests un peu plus complexes et plus difficiles à maintenir. Vous devriez également être conscient que c'est une sorte de "hack" et qu'il y a une raison pour laquelle les méthodes privées ne sont pas normalement accessibles : il s'agit de maintenir l'encapsulation et de masquer les détails d'implémentation, qui pourraient changer. En testant directement les méthodes privées, vous couplez vos tests à ces détails d'implémentation spécifiques et tout changement dans ces méthodes pourrait nécessiter une réécriture de vos tests.
En fin de compte, c'est à vous de décider si les avantages l'emportent sur les inconvénients dans votre cas spécifique.

Fred

Une bonne solution serait d'avoir un concept de classe amie en PHP, hors, cela n'existe pas

ChatGPT

Effectivement, PHP n'a pas de concept de "classe amie" comme le fait C++. Dans C++, une classe amie peut accéder aux méthodes privées et protégées de la classe qui l'a déclarée comme amie, ce qui pourrait être utilisé pour tester ces méthodes.
Sans cette fonctionnalité en PHP, vous devez trouver d'autres moyens de tester vos méthodes privées si vous décidez que c'est nécessaire. C'est une des raisons pour lesquelles certains optent pour la réflexion malgré ses inconvénients.
Si vous avez un cas où vous avez des méthodes privées complexes que vous voulez tester directement, une autre option est de les rendre publiques juste pour des raisons de test et de documenter clairement qu'elles sont destinées à être utilisées à des fins de test uniquement. C'est loin d'être idéal, mais c'est une autre option à considérer.

En fin de compte, il est important de se rappeler que le but des tests unitaires est de s'assurer que chaque partie de votre code fonctionne comme prévu, et non de s'assurer que chaque méthode passe un test. Si vous pouvez tester le comportement de votre classe d'une manière qui a du sens sans avoir besoin de tester chaque méthode privée, cela pourrait être l'approche la plus efficace.

Fred

Je me demande si des méthodes protégées n'auraient pas plus de sens

ChatGPT

Utiliser des méthodes protégées en PHP peut effectivement être une alternative pour des raisons de testabilité. Les méthodes protégées peuvent être appelées par la classe elle-même, ainsi que par toutes les classes qui héritent de celle-ci.
Ainsi, en cas de complexité algorithmique qui ne doit pas être exposée en public tout en souhaitant pouvoir la tester unitairement, créer une sous-classe uniquement pour les tests pour tester ces algorithmes spécifiques pourrait être une solution.
Voici un exemple d'à quoi cela pourrait ressembler :
class MyClass {
    protected function methodToTest($input) {
        // Votre algorithme complexe ici
    }
}
class MyClassTestVersion extends MyClass {
    public function methodToTestWrapper($input) {
        return $this->methodToTest($input);
    }
}
Et voici comment vous pourriez utiliser cela dans vos tests PHPUnit :
public function testMethodToTest() {
    $testObject = new MyClassTestVersion();
    $result = $testObject->methodToTestWrapper('input');
    // Vos assertions ici
}
C'est un moyen d'accéder à la méthode sans l'exposer en tant que publique et sans utiliser la réflexion PHP. Cependant, cette solution a ses propres limites et inconvénients. L'un d'eux est que si les méthodes protégées sont trop nombreuses, cela peut alourdir la classe test et la rendre plus difficile à gérer. De plus, si la logique des méthodes protégées change, les tests doivent être ajustés de la même manière. Et si une méthode privée est utilisée par plusieurs méthodes protégées, alors elle sera testée de manière répétée, ce qui rend les tests moins efficaces. L'équilibre approprié dépend donc de chaque cas particulier.

Fred

Une méthode protégée ne devrait justement pas changer, car c'est un contrat avec les classes qui en héritent, et les tester, cela a beaucoup de sens en fait.

ChatGPT

Tout à fait, vous avez raison. Les méthodes protégées sont effectivement une partie du contrat de la classe avec ses sous-classes, tout comme les méthodes publiques sont un contrat avec tout code externe qui utilise la classe.
Tester les méthodes protégées a donc du sens, car cela permet de garantir que la classe respecte son contrat même lorsque celle-ci évolue. En toute rigueur, c'est même nécessaire lorsque vous suivez une méthodologie de développement piloté par les tests (Test-Driven Development ou TDD), où chaque partie du code doit être couverte par des tests.
C'est une bonne pratique de garder ce contrat aussi stable que possible pour ne pas casser les sous-classes qui dépendent de ces méthodes. Si vous devez changer le comportement de ces méthodes, il est important de le faire de manière à ne pas casser ce contrat. C'est là que les tests unitaires des méthodes protégées peuvent être très utiles, pour vérifier que vous n'avez pas introduit de régressions lors de la modification de ces méthodes.
Il est donc justifié de tester vos méthodes protégées si cela correspond à votre logique d'organisation pour le code et à votre stratégie de test. Gardez cependant à l'esprit qu'il peut toujours être bénéfique de travailler au découplage et à la simplification de vos classes, en évitant autant que possible un grand nombre de méthodes protégées, conformément aux principes du SOLID et du développement orienté objet.

Fred

Sur les méthodes privées, un développeur peut facilement se dire : "je peux changer cette méthode, voir la supprimer, c'est pas grave, elle est privée". Mais en faisant ça, il va casser mes tests et peut-être que cela le conduira à constater certains cas d'usage qu'il n'avait pas identifié. Peut-être qu'une annotation sur ma méthode permettrait de prévenir le développeur qu'il y a des tests associés, avant qu'il ne s'en rende compte plus tard. Une annotation "@see" par exemple

ChatGPT

Votre suggestion d'utiliser une annotation "@see" est une excellente idée pour signaler qu'une méthode privée a des tests associés. Cela peut aider à renforcer la communication au sein de l'équipe de développement et à faire comprendre à quelqu'un qui modifie cette méthode qu'il doit aussi vérifier et potentiellement modifier les tests associés.
Cela pourrait ressembler à ceci dans votre code:
/**
 * @see \Tests\Unit\YourClassTest::testYourPrivateMethod
 */
private function yourPrivateMethod()
{
    // code
}
Cependant, notez que cette annotation doit être entretenue : si le test est renommé ou déplacé, l'annotation doit être mise à jour.
Il est également important de noter qu'une bonne couverture de tests des méthodes publiques devrait également attraper les cas où une modification d'une méthode privée engendre des erreurs.
Dans tous les cas, la décision de tester ou non les méthodes privées doit être prise en fonction du contexte spécifique du projet, de l'équipe, et du code lui-même. L'idée est de tester ce qui est nécessaire pour avoir confiance dans le fonctionnement correct de votre système, tout en équilibrant cet effort avec le temps de développement et la maintenabilité du code.

Fred

Oui, je suis d'accord, cela doit rester à la marge, et favoriser les tests de méthodes publiques. Je m'interrogeais sur cette pratique pour décomplexifier les tests et éventuellement faciliter l'ajout de tests sur du code legacy mal conçu. Je préfère des tests sur méthodes privées que pas de test du tout

ChatGPT

Tout à fait, je suis d'accord avec vous et vous avez une très bonne réflexion sur ce sujet.
Effectivement, lorsque vous travaillez sur du code legacy, vous n'avez pas toujours la possibilité de refactoriser tout ce que vous voudriez. Il est donc crucial d'avoir des tests pour garantir le bon fonctionnement de votre application, même si cela implique de tester des méthodes privées.
Et comme vous l'avez bien dit, dans certains cas le test d'une méthode privée peut être moins complexe et plus rapide à mettre en place que le test de la méthode publique qui l'utilise, notamment si cela évite de devoir mocker de nombreux objets.
En résumé, tester des méthodes privées peut avoir du sens dans certaines situations, notamment dans le cadre de code legacy et quand cela permet de rendre les tests plus simples et plus fiables. C'est une pratique à utiliser avec parcimonie et discernement, en gardant en tête l'objectif principal des tests unitaires : s'assurer de la fiabilité et de la qualité de votre code.

Chat: Unit test of private methods

Frédéric Bouchery — Thu, 26 Oct 2023 15:11:23 +0000

(Traduction française: Chat : Test unitaire sur des méthodes privées)

I present to you here the conversation I had with ChatGPT (version 4) regarding unit testing of private methods, as I found the exercise interesting.
The text in bold was added by me afterward to add some emphasis.

A sentence that I really like:

The goal of unit tests is to make sure each part of your code works as expected, not to ensure each method passes a test

Fred

I want to setup unit tests with PHPUnit. In PHP, what do you think about testing private methods?

ChatGPT

Typically, it is not recommended to directly test private methods in PHPUnit. Private methods are considered implementation details of the class and should only be indirectly tested through the public methods that use them.
If you feel the need to test a private method directly, it could indicate a design problem. Maybe the class is doing too much and could be refactored to move this functionality to a new class where it would be public and could be tested directly.
However, if you absolutely must test a private method for some reason, you can use reflection in PHP to make a private method accessible and then test it. But again, this should be an exception rather than the rule in most cases.

Fred

There's a portion of the algorithmic code that I would like to validate, but I don't want it to be accessible from the outside. If I place this code in a separate class, it would be like making it accessible, even though it has no advantages outside the context of my class. The tests are only for the public methods, forcing me to build mock objects and making the tests complex. If I test my private method, I will have very simple tests.

ChatGPT

In this case, if you think that testing your private methods directly brings you value and improves the quality of your code, then you should do it.
After all, the goal of unit tests is to ensure that your code does what it's supposed to do and help you identify and fix bugs. If testing a private method directly helps you achieve these goals, then there is no reason not to do it.
As mentioned before, you can use reflection to access private methods and test them. Here is an example of how you can do it in PHP:
$className = new YourClass();
$reflector = new ReflectionClass($className);
$method = $reflector->getMethod('yourPrivateMethod');
$method->setAccessible(true);
$result = $method->invokeArgs($className, [$arg1, $arg2]);
// now you can make assertions on $result
However, this can make your tests a bit more complex and harder to maintain. You should also be aware that this is a kind of "hack" and there's a reason why private methods are not normally accessible - it's about maintaining encapsulation and hiding implementation details which could change. By directly testing private methods, you're coupling your tests to these specific implementation details and any changes to these methods could require a rewrite of your tests.
Ultimately, it's up to you to decide if the benefits outweigh the drawbacks in your specific case.

Fred

A good solution would be to have a concept of friend classes in PHP, but it doesn't exist.

ChatGPT

Indeed, PHP does not have a concept of "friend classes" as C++ does. In C++, a friend class can access private and protected methods of the class that declares it as a friend, which could be used to test these methods.
Without this feature in PHP, you have to find other ways to test your private methods if you decide that's necessary. That's why some people choose reflection despite its drawbacks.
If you have a case where you have complex private methods you want to test directly, another option is to make them public just for testing purposes and clearly document that they are intended for testing only. This is far from ideal but it's another option to consider.
In the end, it's important to remember that the goal of unit tests is to make sure each part of your code works as expected, not to ensure each method passes a test. If you can test the behavior of your class in a way that makes sense without needing to test every private method, that might be the most efficient approach.

Fred

I wonder if protected methods wouldn't make more sense.

ChatGPT

Using protected methods in PHP can indeed be an alternative for testability reasons. Protected methods can be called by the class itself, and by all the classes that inherit from it.
So in cases of algorithmic complexity that should not be publicly exposed while wishing to be able to unit test it, creating a subclass just for testing to test these specific algorithms could be a solution.
This is what it could look like:
class MyClass {
    protected function methodToTest($input) {
        // Your complex algorithm here
    }
}
class MyClassTestVersion extends MyClass {
    public function methodToTestWrapper($input) {
        return $this->methodToTest($input);
    }
}
And this is how you could use it in your PHPUnit tests:
public function testMethodToTest() {
    $testObject = new MyClassTestVersion();
    $result = $testObject->methodToTestWrapper('input');
    // Your assertions here
}
This is a way to access the method without exposing it as public and without using PHP reflection. However, this solution has its own limitations and drawbacks. One of them is that if the protected methods are too many, it can burden the test class and make it more difficult to manage. Furthermore, if the logic of protected methods changes, the tests must be adjusted in the same way. And if a private method is used by several protected methods, then it will be tested repeatedly, which makes the tests less effective. The appropriate balance therefore depends on each particular case.

Fred

A protected method should not change because it's a contract with the classes that inherit from it, and testing them makes a lot of sense, in fact.

ChatGPT

Absolutely, you're right. Protected methods are indeed part of the contract of the class with its subclasses, just like public methods are a contract with any external code that uses the class.
Testing protected methods, therefore, makes sense, as it ensures that the class fulfills its contract even as it evolves. Strictly speaking, it's even necessary when you follow a Test-Driven Development (TDD) methodology where every part of the code must be covered by tests.
It's important to keep this contract as stable as possible so as not to break the subclasses that depend on her methods. If you need to change the behavior of these methods, it's important to do so in a way that doesn't break this contract. This is where unit testing of the protected methods can be very useful - to verify that you haven't introduced regressions when modifying these methods.
So it's justified to test your protected methods if it matches your logic of code organization and your testing strategy. However, bear in mind that it is always beneficial to work on decoupling and simplifying your classes, avoiding as much as possible a great number of protected methods, in accordance with the principles of SOLID and object-oriented development.

Fred

On private methods, a developer can easily tell himself: "I can change this method, or even delete it, it's not a big deal", it's private. But by doing that, it's going to break my tests and maybe that will lead him to notice certain cases of use that he had not identified. Maybe an annotation on my method would warn the developer that there are associated tests before he finds out later. An "@see" annotation for example.

ChatGPT

Your suggestion to use an "@see" annotation is an excellent idea to signal that a private method has associated tests. This can help reinforce communication within the development team and make someone who modifies this method understand that they need to also check and potentially modify the associated tests.
This could look like this in your code:
/**
 * @see \Tests\Unit\YourClassTest::testYourPrivateMethod
 */
private function yourPrivateMethod()
{
    // code
}
However, note that this annotation must be maintained: if the test is renamed or moved, the annotation must be updated.
It's also important to note that good test coverage of public methods should also catch cases where a modification of a private method leads to errors.
In any case, the decision to test or not test private methods should be made based on the specific context of the project, the team, and the code itself. The idea is to test what is necessary to have confidence in the correct functioning of your system, while balancing this effort with development time and code maintainability.

Fred

Yes, I agree, this should remain marginal, and prioritize tests of public methods. I was wondering about this practice to simplify tests and possibly facilitate the addition of tests on poorly designed legacy code. I prefer tests on private methods than no test at all.

ChatGPT

Quite right, I agree with you and you have very good thinking on this subject.
Indeed, when working with legacy code, you don't always have the opportunity to refactor everything you would like. It is therefore crucial to have tests to ensure the proper functioning of your application, even if it means testing private methods.
And as you rightly said, in certain cases the test of a private method can be less complex and quicker to set up than the testing of the public method that uses it, notably if it avoids having to mock numerous objects.
In summary, testing private methods can make sense in certain situations, notably in the framework of legacy code and when this allows the tests to be simpler and more reliable. It is a practice to use sparingly and discerningly, keeping in mind the main objective of unit tests: to ensure the reliability and quality of your code.

DX : setter, wither and mutants

Frédéric Bouchery — Tue, 04 Apr 2023 13:20:01 +0000

(English version: https://dev.to/fredbouchery/dx-setter-wither-and-mutants-29e6)

Quand je conçois un code, je passe beaucoup de temps à réfléchir à sa DX (Developer eXperience), c'est d'ailleurs pour cela que j'apprécie les "test before", car cela me permet de réfléchir à la façon d'utiliser le code avant de l'implémenter.

Dernièrement, je concevais une classe de configuration pour une couche d'accès à une BDD et voici la façon dont j'avais initialement imaginé son usage :

<?php
$conf = (new ConnectionConfig())
    ->connection('main')
        ->driver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->host('127.0.0.1', 3306)
            ->credentials('root', 'root')
        ->replica()
            ->host('127.0.0.1', 3307)
            ->credentials('readonly', 'readonly')
;

Au niveau implémentation, c'est une interface chaînée (fluent interface) assez simple :

connection(string $name) vient définir une propriété "$currentConnectionName"
primary() ou replica() viennent définir une propriété $currentReplicationServer

Ensuite, quand on appelle host() ou credentials(), j'utilise les propriétés "$currentXxxx" pour stocker l'information.

Puis, j'ai voulu définir comment j'allais lire ces informations, et j'ai commencé à écrire ça :

<?php
[
    'login' => $login,
    'password' => $password
] = $conf
    ->connection('main')
    ->primary()
    ->getCredentials()
;

Premier constat : Pffff ... j'ai eu la flemme de définir un objet "ServerCredentials" pour y stocker le login et le pass, alors qu'un tableau associatif faisait bien l'affaire. Ne me regardez pas avec cette expression sévère, on l'a tous fait ... les jours de flemme, et comme le dirait Krän : "Y'a des jours, faut pas m'chercher ! Et y'a des jours tous les jours !". Mais c'est pas le débat aujourd'hui, voyons le problème suivant que je voudrais mettre en valeur.

Pour lire l'identité, j'ai utilisé un getter getCredentials() alors que pour la définir, j'ai utilisé la simple méthode credentials($login, $pass), car je trouvais ça plus cool pour ma DX.

Simplement, quand on se place du point de vue de la personne qui va récupérer la définition, déjà, ce n'est pas habituel d'avoir un getter et une méthode d'assignation qui ne commence pas par "set", et en plus, cela peut être confusant quand l'IDE va autocompléter et proposer ces deux méthodes.

Bon, certes, il n'y a pas trop d'ambiguïté, car une méthode avec deux paramètres $login et $pass, il est probable qu'elle permette de les assigner. Mais, j'ai quand même préféré changer ça avec des setters.

Oui, car quand on conçoit une bonne DX, il faut éviter de trop changer les habitudes des développeuses et des développeurs ! Même si votre idée semble révolutionnaire, innovante, jamais faite auparavant, cela peut desservir votre DX drastiquement.

Me voilà donc à changer la définition :

<?php
$conf = (new ConnectionConfig())
    ->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

Et là, une nouvelle difficulté s'est présenté à moi : les mutants !

Regardez ce code:

<?php
$serverIp = '127.0.0.1';
$login = 'root';
$password = 'root';

$conf = new ConnectionConfig();

$primary = $conf->connection('main')->primary();
$replica = $conf->connection('main')->replica();

// Define hosts
$primary->setHost($serverIp, 3306);
$replica->setHost($serverIp, 3307);

// Define credentials
$primary->setCredentials($login, $password);
$replica->setCredentials($login, $password);

Oui, on imagine une façon d'utiliser un code et la personne va le faire d'une toute autre manière, c'est son droit.

Seulement, dans le cas présent, il y a un bug assez gênant : le serveur primaire n'est jamais défini. Si vous ne voyez pas pourquoi, je vous laisse essayer de comprendre avant de lire l'explication qui va suivre.
.
.
.
.
.
.
.
.
.
Comme je l'ai indiqué au début, quand on appelle primary() ou replica(), on vient définir une propriété $currentReplicationServer, et comme j'utilise une interface "fluent", les variables $primary et $replica contiennent toutes les deux la même instance d'objet. Lors de l'appel à ->replica() la propriété $currentReplicationServer va donc être modifiée pour indiquer que l'on configure le réplica, ce qui concerne également l'instance dans la variable $primary (je vous laisse relire si vous n'avez pas bien compris).

On tombe dans un grand classique en PHP (et d'autres langages) : la mutabilité des objets.

Pour résoudre cela, on utilise l'auto-clonage, on change la propriété et on retourne la nouvelle instance. On passe donc de :

<?php
public function primary(): self
{
    $this->currentReplicationConfiguration = 'primary';

    return $this;
}

À :

<?php
public function primary(): self
{
    $self = clone $this;

    $self->currentReplicationConfiguration = 'primary';

    return $self;
}

Et on va appliquer cette technique sur l'ensemble des méthodes, sauf que ... ça ne fonctionne pas. Car dans le cas :

<?php
$conf = new ConnectionConfig();

$primary = $conf->connection('main')->primary();
$replica = $conf->connection('main')->replica();

Ce que je souhaite, c'est que $conf contienne tous les éléments de configuration, pour la connexion "main", avec le serveur primaire et le réplica, et au final, on a 3 instances de la classe de configuration avec des valeurs dissociées.

Et c'est bien tout le problème du design "fluent" couplé à un changement d'état (stateful vs stateless) : Si le comportement d'une méthode dépend de l'appel d'une autre, vous êtes dans le pétrin !

Il y a une possibilité pour résoudre partiellement ça, c'est en faisant comprendre au développeur, ou à la développeuse, que la méthode retourne une nouvelle instance : on va remplacer les "setters" par des "withers" :

<?php
$conf = new ConnectionConfig();
$primary = $conf->withConnection('main')->withPrimary();

En utilisant le préfixe "with" cela indique que le retour sera une nouvelle instance de l'objet, donc $conf n'est pas la même instance que $primary. Le développeur ou la développeuse va donc devoir chaîner ses appels, sinon le résultat final ne contiendra pas ce qu'il souhaite.

En réalité, on n'a pas résolu la question par du code supplémentaire, mais juste par un simple renommage, car, oui, la conception d'un code, et d'une bonne DX, passe aussi par son nommage.

Le code final serait :

<?php
$conf = (new ConnectionConfig())
    ->withConnection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->withPrimary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->withReplica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

Et, si on revient à l'accès, cela donne :

<?php
[
    'login' => $login,
    'password' => $password
] = $conf
    ->withConnection('main')
    ->withPrimary()
    ->getCredentials()
;

Franchement, je trouve pas ça dingue comme DX, car dans mon petit cerveau, j'ai tendance à associer les "withers" à de la construction et non de l'accès.

C'est la quadrature du cercle, vous ne trouvez pas ?

En fait non, c'est tout simplement parce que j'ai fait fausse route depuis le début, et cela a commencé quand j'ai écrit que j'avais eu la flemme !

Ma classe aurait dû s'appeler "ConnectionsConfiguration" avec un "s" et un mot complet (Arrêtez les raccourcis, c'est pas 7 caractères de plus qui vont impacter votre productivité)
Il ne devrait y avoir qu'une seule méthode "connection(string $name)" qui retourne un objet "ConnectionConfiguration" (sans le "s" donc)
ConnectionConfiguration dispose de trois méthodes setDriver(), primary() et replica(), dont les deux dernières retournent des instances mutables de ServerConfiguration.
ServerConfiguration contient quatres méthodes setHost(), setCredentials(), getHost() et getCredentials() gérant des objets ServerHost et ServerCredentials

Au final, le code sera :

<?php
$conf = (new ConnectionsConfiguration())
    ->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

Sauf qu'avec ce code, je n'ai plus une interface fluent et ... j'ai une erreur fatale !
Si vous regardez attentivement, après le setCredentials(), j'appelle replica(), mais cette méthode n'existe pas, car setCredentials() ne retourne pas un ConnectionConfiguration mais un ServerCredentials. De même, la variable "$conf" ne contient pas un objet ConnectionsConfiguration. Bref, sans interface fluent, il faudrait écrire comme ceci :

<?php
$conf = new ConnectionsConfiguration();
$conf->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
;
$conf->connection('main')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

C'est tout de suite moins joli que les enchaînements d'appels d'une fluent, mais on aura beaucoup moins de risque de bug.

Pour l'accès à la configuration, cela donne :

<?php
$credentials = $conf
   ->connection('main')
   ->primary()->
   ->getCredentials()
;
$login = $credentials->login;
$password = $credentials->password;

Les plus attentifs auront noté que mes classes sont mutables, et pour certains, c'est une hérésie, un scandale, une honte qui devrait me conduire au bûcher ! À ceux là, je répondrais :
Oui, mais cela générerait beaucoup plus de problèmes qu'il n'en résout et casserait ma DX. Alors, je vous renvois au mantra de Krän : "Y'a des jours, faut pas m'chercher ! Et y'a des jours tous les jours !".

En résumé :

Placez-vous du point de vue de l'utilisation et non de l'implémentation
N'innovez pas trop, les gens ont des habitudes
Ne soyez jamais flemmards
Utilisez l'immutabilité avec parcimonie
Attention aux interfaces fluents sur les objets stateful
Lisez Krän, c'est une BD déjantée à souhait

DX: setter, wither and mutants

Frédéric Bouchery — Tue, 04 Apr 2023 13:18:56 +0000

(Version française: https://dev.to/fredbouchery/dx-setter-wither-and-mutants-4b44)

When I design my PHP code, I spend a lot of time thinking about its DX (Developer eXperience), which is why I appreciate "test before" because it allows me to think about how to use the code before implementing it.

Recently, I was designing a configuration class for a database access layer and here's how I initially planned to use it:

<?php
$conf = (new ConnectionConfig())
    ->connection('main')
        ->driver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->host('127.0.0.1', 3306)
            ->credentials('root', 'root')
        ->replica()
            ->host('127.0.0.1', 3307)
            ->credentials('readonly', 'readonly')
;

The implementation is a fairly simple fluent interface:

connection(string $name) sets the "$currentConnectionName" property.
primary() or replica() sets the "$currentReplicationServer" property.
Then, when host() or credentials() is called, I use the "$currentXxxx" properties to store the value.

Next, I wanted to define how I would read these values, and I started writing this:

<?php
[
    'login' => $login,
    'password' => $password
] = $conf
    ->connection('main')
    ->primary()
    ->getCredentials()
;

First observation: Ouch... I was too lazy to define a "ServerCredentials" object to store the login and password, even though an associative array would do just fine. Don't look at me with that stern expression, we've all done it... on lazy days, and as Krän would say: "There are days you shouldn't mess with me! And there are days every day!" But that's not the debate today; let's look at the next problem I want to highlight.

To read the credentials, I used a getCredentials() getter, while to define it, I used the simple credentials($login, $pass) method because I found it cooler for my DX.

Actually, from the point of view of the person who will retrieve the definition, it's not usual to have a getter and an assignment method that doesn't start with "set," and it can be confusing when the IDE autocompletes will suggest these two methods.

Obviously, a method with two parameters $login and $pass should be the method which assigned the value, but, I still preferred to change that with setters.

Yes, because when you design a good DX, you should not change too much the way developers do things! Even if your idea seems revolutionary, innovative, never done before, it can drastically harm your DX.

Here how I changed the definition:

<?php
$conf = (new ConnectionConfig())
    ->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

And then, a new difficulty came to me: mutants!

Look at this:

<?php
$serverIp = '127.0.0.1';
$login = 'root';
$password = 'root';

$conf = new ConnectionConfig();

$primary = $conf->connection('main')->primary();
$replica = $conf->connection('main')->replica();

// Define hosts
$primary->setHost($serverIp, 3306);
$replica->setHost($serverIp, 3307);

// Define credentials
$primary->setCredentials($login, $password);
$replica->setCredentials($login, $password);

Yes, we designed a way to use our code and developer will do it in a completely different way, it's his right.

However, in this case, there is a rather embarrassing bug: the primary server configuration is never defined. If you don't see why, I'll let you try to understand before reading the explanation that follows.
.
.
.
.
.
.
.
.
.
As I mentioned at the beginning, when we call primary() or replica(), we are setting a $currentReplicationServer property, and since I am using a fluent interface, the $primary and $replica variables both contain the same object instance. When calling ->replica(), the $currentReplicationServer property will therefore be modified to indicate that we are configuring the replica, which also affects the instance in the $primary variable (I'll let you reread if you didn't understand it well).

Now, we fall into a classic pitfall in PHP (and other languages): object mutability.

To solve this, auto-cloning is used, the property is changed, and the new instance is returned. So, we go from:

<?php
public function primary(): self
{
    $this->currentReplicationConfiguration = 'primary';

    return $this;
}

To:

<?php
public function primary(): self
{
    $self = clone $this;

    $self->currentReplicationConfiguration = 'primary';

    return $self;
}

And this technique is applied to all methods, but... it doesn't work. Because in this case:

<?php
$conf = new ConnectionConfig();

$primary = $conf->connection('main')->primary();
$replica = $conf->connection('main')->replica();

What I want is that $conf contains all the configuration elements, for the "main" connection, with the primary server and the replica, and finally, we have 3 instances of the configuration class with dissociated values.

And that's the problem with fluent design coupled with stateful/stateless design: If the behavior of a method depends on the call of another one, you are in trouble!

There is a way to partially solve this, by making the developer understand that the method returns a new instance: we will replace the setters by withers:

<?php
$conf = new ConnectionConfig();
$primary = $conf->withConnection('main')->withPrimary();

Using the prefix "with" indicates that the return will be a new instance of the object, so $conf is not the same instance as $primary. The developer must chain his calls otherwise he will not get the result he expects.

In reality, we haven't solved the problem with additional code, but simply by renaming it, because yes, naming is part of the design and DX.

The final code would be:

<?php
$conf = (new ConnectionConfig())
    ->withConnection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->withPrimary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->withReplica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

And, if we go back to the access, it would be:

<?php
[
    'login' => $login,
    'password' => $password
] = $conf
    ->withConnection('main')
    ->withPrimary()
    ->getCredentials()
;

Honestly, I don't think this DX is amazing because in my small brain, I tend to associate "withers" with building rather than access.

It's like squaring the circle, don't you think?

Actually, no, it's simply because I went the wrong way from the start, and it started when I wrote that I was lazy!

My class should have been called "ConnectionsConfiguration" with an "s" and a complete word (Stop taking shortcuts, it's not 7 more characters that will impact your productivity)
There should only be one method "connection(string $name)" that returns a "ConnectionConfiguration" object (without the "s")
ConnectionConfiguration has three methods setDriver(), primary(), and replica(), the latter two returning mutable instances of ServerConfiguration.
ServerConfiguration contains four methods setHost(), setCredentials(), getHost(), and getCredentials() managing ServerHost and ServerCredentials objects.

In the end, the code will be:

<?php
$conf = (new ConnectionsConfiguration())
    ->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

Except that with this code, I don't have a fluent interface anymore and ... I have a fatal error!

If you look carefully, after the setCredentials(), I call replica(), but this method does not exist, because setCredentials() does not return a ConnectionConfiguration but a ServerCredentials. Also, the variable $conf does not contain a ConnectionsConfiguration object. In short, without a fluent interface, we would have to write like this:

<?php
$conf = new ConnectionsConfiguration();
$conf->connection('main')
        ->setDriver(DriverInterface::DRIVER_MYSQL)
        ->primary()
            ->setHost('127.0.0.1', 3306)
            ->setCredentials('root', 'root')
;
$conf->connection('main')
        ->replica()
            ->setHost('127.0.0.1', 3307)
            ->setCredentials('readonly', 'readonly')
;

It's less beautiful than a fluent call chain, but there is less risk of a bug.

For the access to the configuration, it gives :

<?php
$credentials = $conf
   ->connection('main')
   ->primary()
   ->getCredentials()
;
$login = $credentials->login;
$password = $credentials->password;

The most attentive may have noticed that my classes are mutable, and for some, it's heresy, scandal, a shame that should lead me to the stake! To those, I would reply:
Yes, but it would generate more problems than it solves and break my DX. So, I refer you to Krän's mantra: "There are days when you shouldn't mess with me! And there are days every day!".

In summary:

Place yourself from the user's point of view and not the implementation's
Don't innovate too much, people have patterns
Don't be lazy
Use immutability sparingly
Be careful with fluent interfaces on stateful objects
Read Krän, it's a delightfully insane comic book.

Why your class must be final

Frédéric Bouchery — Sat, 01 Apr 2023 19:00:00 +0000

(Version Française: Pourquoi il faut déclarer ses classes "final")

When coding with other developers, such as in peer or mob programming, they often ask me: "Why do you declare all your classes as final?". My response has always been that it's a good practice for me, inherited from my far experience with Delphi, where all classes are "final" by default. However, when asked why it's a good practice, I realized I needed to be more specific.

Using the final keyword can help avoid inheritance hell which refers to large and complex class hierarchies that are difficult to navigate and understand. Inheritance can make testing and debugging more difficult, especially when dealing with complex inheritance chains and dependencies. In other words, inheritance can lead to tight coupling, increased complexity, and code brittleness.

Another issue with inheritance is that it creates a strong coupling between the base class and the derived class, making it harder to change the base class without affecting the derived classes. This can make the code harder to maintain over time.

Recently, I was making changes to a PHP library that use database terminology master/slave and I wanted to make theses modifications:

rename methods "master" to "primary" and "slave" to "replica"
add deprecated methods "master" and "slave" that call "primary" and "replica" methods
add a comment to the "slave" deprecated method to explain the reasons for the change (due to negative connotations).

However the class define a property called $slaveConnection which was declared as protected. I would have liked to change also its name, but couldn't do so because it could be used by a child class.
I considered declaring the property as private and using magic getter and setter to allow child class to write and read the deprecated property name, but felt that this added unnecessary complexity to solve something I'm pretty sure it doesn't exists. Although this library is open-sourced, it's not very popular, and the probability that this class is overrided by someone, lonely in a dark place, is very close to zero.

To avoid introducing breaking changes to the code, I kept this offensive name, and added a comment explaining that it was being kept for compatibility reasons, but I didn't approve of the name.

As you understand, because the class is not final, and even though I was sure that it wouldn't be overridden, I can't make my change.
If the developer who designed this class had wrote all his classes as final by default, I wouldn't have encountered this issue, and it's safer to remove the final keyword only when necessary to override a class.

In conclusion, making all classes final by default can save time for future generations of developers who will maintain the code.

(source of photos: pexels.com)

Pourquoi il faut déclarer ses classes "final"

Frédéric Bouchery — Sat, 01 Apr 2023 17:51:58 +0000

(English version: Why your class must be final)

Lorsque je code avec d'autres développeuses ou développeurs, en pair programming ou en groupe, on me demande souvent : "Pourquoi déclares-tu toutes tes classes "final?".

Ma réponse a toujours été : C'est une bonne pratique pour moi, héritée de mon expérience avec Delphi, où toutes les classes sont "final" par défaut.
Cependant, lorsque l'on me demande pourquoi c'est une bonne pratique, j'ai réalisé que je devais être plus précis.

L'utilisation du mot-clé "final" peut aider à éviter le inheritance hell, en référence aux interminables et complexes hiérarchies de classes, dans laquelle il est difficiles de se retrouve, et de comprendre.
L'héritage peut rendre les tests et le débogage plus difficiles, en particulier lorsqu'il s'agit de chaînes d'héritage complexes avec des dépendances dans tous les sens. En d'autres termes, l'héritage peut entraîner un code fragile et une complexité accrue.

Un autre problème avec l'héritage est qu'il crée un couplage fort entre la classe de base et la classe dérivée, rendant plus difficile le changement de la classe de base sans affecter les classes dérivées et cela peut rendre le code plus difficile à maintenir dans le temps.

Récemment, j'ai apporté des modifications à une bibliothèque PHP qui utilise la terminologie "maître/esclave" et je voulais effectuer les modifications suivantes :

Renommer les méthodes "master()" en "primary()" et "slave()" en "replica()"
Ajouter des méthodes dépréciées "master()" et "slave()" qui appellent les méthodes "primary()" et "replica()"
Ajouter un commentaire à la méthode dépréciée "slave()" pour expliquer les raisons du changement (connotations négatives).

Le problème, c'est que la classe définissait également une propriété appelée "$slaveConnection" qui était déclarée comme protected.
J'aurais aimé changer également son nom, mais je ne pouvais pas le faire car elle était peut-être utilisée par une classe enfant.
J'ai envisagé de déclarer la propriété comme private et utiliser des getters et des setters magiques pour permettre aux classes enfants d'écrire et de lire le nom de la propriété déprécié, mais j'ai estimé que cela ajoutait une complexité inutile pour résoudre quelque chose dont je suis sûr que ce n'est pas utilisé. Bien que cette bibliothèque soit open source, elle n'est pas très populaire, et la probabilité que cette classe soit redéfinie, dans un obscure bout de code, fait par une personne dans un coin sombre d'internet, est proche de zéro.

Pour éviter d'introduire des changements qui casserait la compatibilité du code, j'ai conservé ce nom offensant et ajouté un commentaire expliquant qu'il était conservé pour des raisons de compatibilité, mais je n'approuvais pas le nom.

Comme vous le comprenez, parce que la classe n'est pas final, et même si je suis sûr qu'elle n'est pas redéfinie, je ne peux pas faire mon changement. Si le développeur ou la développeuse qui avait conçu cette classe, avait le réflexe de déclarer final toutes ses classes, je n'aurais jamais rencontré ce problème. D'ailleurs, si on veut redéfinir la classe plus tard, il est beaucoup plus simple de supprimer le mot clé final sans générer de casse de compatibilité.

En conclusion, déclarer toutes vos classes final par défaut peut faire gagner du temps aux générations futures de développeurs qui maintiendront votre code.

(source des photos: pexels.com)

Performance of UUIDs

Frédéric Bouchery — Sun, 22 Mar 2020 22:55:11 +0000

(version francaise)

Recently, while analyzing the performance of an application using blackfire, we found that a significant amount of time was spent transforming binary UUIDs into strings and vice-versa.

It has to be mentioned that the UUIDs are stored in the database using binary format, and the application having a Rest API, the UUIDs are therefore always converted into strings as "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxx-xxxxxxxx", either to return the JSON response or to process requests with UUIDs.

Like most developers, the application’s developers have relied on the "Ramsey/UUID" package, which seems to be the solution commonly used for handling UUIDs. The excellent reputation of this component has conducted us to look for optimization in the application without challenging the relevance of Ramsey/UUID.

Recently, while reading JoliCode's article "UUID generation in PHP" and the discussion about a pull request on Symfony UID, we looked a bit more into the way our application manipulates UUIDs, because as Grégoire Pineau says, if Symfony's polyfill is as efficient, we might have to reconsider the use of Ramsey/UUID.

We did some profiling of the application, and we found that we spend a lot of time encoding/decoding UUIDs rather than generating them. This might be a common situation for many applications.

In this context, is JoliCode's benchmark still relevant, since it compares the generation of UUIDs?

So we've did other benchmarks, but this time we did it by comparing an operation that converts a binary UUID into a string and a string into a binary.

With Ramsey/UUID, this is done when you create a Uuid object from a binary and then convert it back to a binary:

<?php
\Ramsey\Uuid\Uuid::fromBytes($bytes)->getBytes();

We created a Uuid class that uses the PHP extension "uuid", as a ValueObject:

<?php
final class Uuid {
    /**
     * @var string
     */
    private $uuid;

    public function __construct(string $uuid)
    {
        if (\uuid_is_valid($uuid) === false) {
            throw new RuntimeException("Wrong UUID format");
        }
        $this->uuid = $uuid;
    }

    public function equals(Uuid $other): bool
    {
        return $this->uuid === $other->uuid;
    }

    public static function fromBytes(string $bytes): self
    {
        return new self(\uuid_unparse($bytes));
    }

    public function getBytes(): string
    {
        return \uuid_parse($this->uuid);
    }

    public function toString(): string
    {
        return $this->uuid;
    }
}

Even before running the benchmark for Uuid::fromBytes($bytes)->getBytes(), we already knew that it would outperform Ramsey/UUID because there are no calls to factories and other codecs. Moreover, internally, Ramsey/UUID keeps the UUID in a decomposed field structure, while in the previous code, the UUID is stored as a string.

So we looked at how the polyfill Symfony is implemented, which allows to replace the functions of the UUID extension when it is not available, and we figured out that it could be optimized, because some greedy processing was done in uuid_unparse() to validate the UUID structure.

Here's how we could optimize it:

<?php
final class Uuid {
    /**
     * @var string
     */
    private $uuid;

    public function __construct(string $uuid)
    {
        if (\preg_match('`^[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}$`Di', $uuid) === 0) {
            throw new RuntimeException("Wrong UUID format");
        }
        $this->uuid = $uuid;
    }

    public function equals(Uuid $other): bool
    {
        return $this->uuid === $other->uuid;
    }

    public static function fromBytes(string $bytes): self
    {
        if (\strlen($bytes) !== 16) {
            throw new RuntimeException("Invalid binary UUID. Length is not 16 bytes");
        }

        $hex = \substr_replace(\bin2hex($bytes), '-', 8, 0);
        $hex = \substr_replace($hex, '-', 13, 0);
        $hex = \substr_replace($hex, '-', 18, 0);
        return new self(\substr_replace($hex, '-', 23, 0));
    }

    public function getBytes(): string
    {
        return \hex2bin(\str_replace('-', '', $this->uuid));
    }

    public function toString(): string
    {
        return $this->uuid;
    }
}

The execution time for 1 million iterations is:

Ramsey => 2583 ms
ext-uuid => 1260 ms
polyfill-symfony => 4020 ms
custom => 642 ms

*(the environment doesn't really matter, just know that the test was done on Ubuntu 19.10 with PHP 7.3.11).

We ran this benchmark many times to be sure, but yes, the code is twice as fast as the UUID extension!

Regarding the generation of UUIDs, as this is an unusual operation for us, we kept using Ramsey/UUID for this.

In our context, we found that Ramsey/UUID is not the best option. But the most surprising thing is that our PHP code is more efficient in encoding/decoding UUIDs than the extension.
So, if you don't have this extension, it's not a big deal, because it's less efficient than the PHP version.

Update: Since writing this article, Nicolas Grekas has submitted a PR to optimize Symfony's polyfill.
Here is the benchmark result with this PR:

Ramsey => 2583 ms
ext-uuid => 1260 ms
polyfill-symfony => 4020 ms
polyfill-symfony-optim => 1145 ms
custom => 642 ms

Many thanks to Nicolas Grekas for reviewing this English translation.

Here is the code used for the benchmark (+ an additional test of the impact on the check in the constructor)

https://gist.github.com/f2r/4f21279732cc1ba81dddc05ef042a1f5

Performance des UUIDs

Frédéric Bouchery — Fri, 20 Mar 2020 16:54:45 +0000

(English version)

Dernièrement, en analysant les performances d'une application au moyen de l'excellent outil blackfire, nous avons constaté un temps non-négligeable passé à transformer des UUIDs binaires en chaînes et vice-versa.

Il faut dire que le stockage des UUIDs dans la base de données est au format binaire, et l'application disposant d'une API Rest, les UUIDS sont donc tout le temps convertis en chaîne de caractères sous la forme "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx", que ce soit pour retourner la réponse en JSON ou pour traiter des requêtes avec des UUIDs.

Comme beaucoup, les développeurs de l'application se sont tournés vers le paquet "Ramsey/UUID", qui semble être la solution majoritairement exploitée dans le cadre de la manipulation d'UUIDs. L'excellente réputation de ce composant, nous a conduit à chercher des solutions d'optimisation dans l'application, sans remettre en doute la pertinence de Ramsey/UUID.

Récemment, à la lecture de l'article de Jolicode "UUID generation in PHP" et du débat autour d'une pull request sur Symfony UID, nous nous sommes penchés un peu plus sur la façon dont l'application manipule les UUIDs, car comme le dit Grégoire Pineau, si le polyfill de Symfony est aussi performant, il faudrait peut-être remettre en cause l'utilisation de Ramsey/UUID.

Seulement, quand on fait quelques statistiques sur l'application, on passe surtout beaucoup de temps à coder/décoder les UUIDs plutôt qu'à en générer, et ça doit être le cas de beaucoup d'applications.

Mais dans ce cas, le benchmark de Jolicode est-il toujours pertinent, dans la mesure où celui-ci fait une comparaison sur la génération d'UUID ?

Nous avons donc fait d'autres benchmarks, mais cette fois-ci, en comparant une opération qui converti un UUID binaire en chaîne et une chaîne en binaire.

Avec Ramsey/UUID, cela est fait quand on crée un objet Uuid depuis un binaire, puis que l'on retransforme cet objet en binaire :

<?php
\Ramsey\Uuid\Uuid::fromBytes($bytes)->getBytes();

Nous avons créé une classe Uuid qui utilise l'extension PHP "uuid", sous la forme d'un ValueObject:

<?php
final class Uuid {
    /**
     * @var string
     */
    private $uuid;

    public function __construct(string $uuid)
    {
        if (\uuid_is_valid($uuid) === false) {
            throw new RuntimeException("Wrong UUID format");
        }
        $this->uuid = $uuid;
    }

    public function equals(Uuid $other): bool
    {
        return $this->uuid === $other->uuid;
    }

    public static function fromBytes(string $bytes): self
    {
        return new self(\uuid_unparse($bytes));
    }

    public function getBytes(): string
    {
        return \uuid_parse($this->uuid);
    }

    public function toString(): string
    {
        return $this->uuid;
    }
}

Avant même de benchmarker un Uuid::fromBytes($bytes)->getBytes(), on sait déjà que ça sera plus performant que Ramsey car il n'y a pas d'appel sur des factories et autres codecs. De plus, en interne, Ramsey conserve l'UUID sous une forme décomposée en plusieurs champs, alors que dans notre code précédent, l'UUID est mémorisé sous sa forme chaîne de caractères.

Nous avons du coup regardé comment était réalisé le polyfill Symfony qui permet de remplacer les fonctions de l'extension UUID quand elles n'existent pas, et nous nous sommes dit qu'il était possible de l'optimiser, car un traitement un peu gourmand était fait lors du uuid_unparse pour valider la structure de l'UUID.

Voici comment nous pourrions réaliser cette optimisation :

<?php
final class Uuid {
    /**
     * @var string
     */
    private $uuid;

    public function __construct(string $uuid)
    {
        if (\preg_match('`^[0-9a-f]{8}(-[0-9a-f]{4}){3}-[0-9a-f]{12}$`Di', $uuid) === 0) {
            throw new RuntimeException("Wrong UUID format");
        }
        $this->uuid = $uuid;
    }

    public function equals(Uuid $other): bool
    {
        return $this->uuid === $other->uuid;
    }

    public static function fromBytes(string $bytes): self
    {
        if (\strlen($bytes) !== 16) {
            throw new RuntimeException("Invalid binary UUID. Length is not 16 bytes");
        }

        $hex = \substr_replace(\bin2hex($bytes), '-', 8, 0);
        $hex = \substr_replace($hex, '-', 13, 0);
        $hex = \substr_replace($hex, '-', 18, 0);
        return new self(\substr_replace($hex, '-', 23, 0));
    }

    public function getBytes(): string
    {
        return \hex2bin(\str_replace('-', '', $this->uuid));
    }

    public function toString(): string
    {
        return $this->uuid;
    }
}

Le temps d’exécution pour 1 million d'itérations nous donne :

Ramsey => 2583 ms
ext-uuid => 1260 ms
polyfill-symfony => 4020 ms
custom => 642 ms

(l'environnement n'a pas beaucoup d'importance, sachez juste que le test a été fait sur Ubuntu 19.10 avec PHP 7.3.11)

Nous avons ré-exécuté ce benchmark plusieurs fois pour en être sûr, mais oui, le code est deux fois plus rapide que l'extension UUID !

Quant à la génération des UUIDs, comme c'est une opération peu courante pour nous, nous avons continué à utiliser Ramsey pour cela.

Dans notre contexte, on s'aperçoit que Ramsey/UUID n'est pas forcement pertinent, mais ce qui est le plus surprenant, c'est que notre code PHP est plus performant dans l'encodage/décodage d'UUID que l'extension.
Donc, si vous n'avez pas cette extension, ce n'est pas bien grave, car elle est moins performante que sa version en PHP.

Update: Depuis l'écriture de cet article, Nicolas Grekas a soumis une PR pour optimiser le polyfill de Symfony.
Voici le benchmark avec le résultat de sa PR:

Ramsey => 2583 ms
ext-uuid => 1260 ms
polyfill-symfony => 4020 ms
polyfill-symfony-optim => 1145 ms
custom => 642 ms

Voici le code utilisé pour le benchmark (+ un test complémentaire de l'impact sur le check à la construction)

https://gist.github.com/f2r/4f21279732cc1ba81dddc05ef042a1f5