La parole est aux speakers : Pol Dellaiera
Jusqu’à l’AFUP Day 2021, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !
La conférence
Lazy CollectionPHP Collection est une bibliothèque utilitaire fonctionnelle pour PHP supérieure à 7.1.3. C'est similaire à d'autres bibliothèques de collections basées sur des tableaux PHP classiques, mais avec un mécanisme "lazy" (paresseux) sous le capot qui s'efforce de faire le moins de travail possible tout en étant aussi flexible que possible. Des fonctions comme array_map (), array_filter () et array_reduce () sont excellentes, mais elles créent de nouveaux tableaux et tout est executé directement avant de passer à l'étape suivante. La librarie PHP Collection exploite les générateurs, les itérateurs et les "yield" PHP pour vous permettre de travailler avec de très grands ensembles de données tout en maintenant l'utilisation de la mémoire aussi faible que possible. Par exemple, imaginez que votre application a besoin de traiter un fichier journal de plusieurs gigaoctets tout en tirant parti des méthodes de cette bibliothèque pour analyser le fichier. Au lieu de lire et de stocker le fichier entier en mémoire à la fois, cette bibliothèque peut être utilisée pour ne conserver qu'une petite partie du fichier en mémoire à un moment donné et executer des opérations sur l'ensemble des données. Vous pouvez trouver le lien de cette librairie ici: https://github.com/loophp/collection |
Lille 28/05/2021 17:10-17:50 |
Quand on lit « Lazy Collection », impossible de s’empêcher de penser à « Doctrine Collection ». Saurais-tu nous dire en quoi ta librairie est différente ?
Le package doctrine / collections est une des raisons pour laquelle j’ai commencé à m’intéresser aux collections. Cependant, le vrai déclencheur a été une pull request de Joseph Silber sur le framework Laravel, le 5 Août 2019. Je l’ai longuement analysée et testée et j’ai commencé à écrire ma propre librairie, principalement afin de tester, comprendre et améliorer certains concepts. Ceci dit c’est vrai, des librairies de collections, il y en a plein et à toutes les sauces, et la sauce curry est assez rare ! La librairie fournie par Doctrine est principalement utilisée par Doctrine. Les résultats d’une requête SQL de type SELECT sont souvent emballés sous une instance de leur collection. Cela permet, entre autre, de facilement appliquer des fonctions de filtrage, de triage et j’en passe. C’est très pratique car le résultat d’une requête est un object, une instance de la collection, et donc il y a moyen facilement de voir les méthodes qui lui sont adjointes, par exemple, avec son IDE et ainsi de manipuler les données. Pour revenir à ta question originelle maintenant, doctrine/collections n’est pas lazy. Chaque appel de méthode s’exécute instantanément en dépit de la taille de l’ensemble des données initiales. Sans compter la couche qui gère les expressions, on pourrait grosso-modo pratiquement réduire cette librairie à un simple utilitaire de manipulation de tableaux. Et donc oui, il y a donc bien une différence fondamentale entre doctrine/collections et loophp/collection. Exemple, à la suite d’une requête d’un service ou d’une base de données, nous récupérons dans la collection Doctrine$collection des millions d’identifiants numériques. Nous souhaitons les filtrer selon leur parité, ensuite renommer les fichiers, ensuite filtrer les fichiers inexistants et enfin récupérer le contenu de chaque fichier.
- Avant même de commencer le foreach,
- Parcourir la collection pour filtrer les nombres pairs,
- Créer un tableau temporaire des résultats,
- Parcourir les résultats afin de renommer en nom de fichier,
- Créer un tableau temporaire des résultats,
- Filtrer les résultats en fonction de l’existence du fichier,
- Créer un tableau temporaire des résultats,
- Chercher le contenu de chaque fichier,
- Créer un tableau des résultats final,
- Itérer.
- Avant même de commencer le \textit{foreach}: rien,
- Dès l’itération du premier élément,
- Si l’élément est pair, renommer l’identifiant en nom de fichier
- Si le fichier existe, chercher le contenu de chaque fichier,
- Envoyer le résultat à l’utilisateur,
- Itérer.
Nous à l’AFUP on adore le curry, doux, fumé… pardon ? Ah ! Curry c’est un style d’écriture du code ? Peux-tu nous expliquer ce qu’est ce style ?
J’adore le curry aussi, autant dans mon plat que dans le code, si pas plus ! Par simplicité et pragmatisme, je vais devoir mixer des termes francophones et anglophones. Le terme vient du nom du mathématicien américain Haskell Curry, oui, Haskell comme le langage, tiens tiens !
La définition suivante l’explique très bien : la curryfication est la transformation d’une fonction à plusieurs arguments en une fonction à un argument (unary function) qui retourne une fonction sur le reste des arguments.
Prenons un exemple trivial: la fonction implode(). Cette fonction est dite binaire et nous devons arriver à la transformer en fonction dite unaire.
Mais comment est-ce possible? Pour se réaliser, cette fonction aura toujours besoin de 2 arguments !
La curryfication de cette fonction reviendrait donc à créer une nouvelle fonction unaire qui admet le premier argument $separator, qui retourne une fonction qui elle-même admet le deuxième argument $strings et qui retourne le résultat final.
Exemple :
$implode = fn(string $separator) => fn(array $strings) => \implode($separator, $strings);
L’avantage de cette technique inventée dans les années 70 (pas si vieille !) permet de composer plus facilement des opérations élaborées à l’aide de plusieurs autres fonctions. Il permet aussi de faciliter la ré-écriture d’un code, d’écrire moins de code ainsi que d’écrire du code moins impératif et plus déclaratif, plus tourné vers la programmation fonctionnelle. Maintenant, dans le contexte qui nous importe aujourd’hui, à savoir les collections lazy et plus particulièrement loophp/collection, j’ai eu recours à cette technique presque partout. En effet, lorsque vous passez des arguments dans le constructeur d’une class, il y a de fortes chances que ces arguments soient gardés en mémoire via des propriétés. Et donc, afin de réduire l’emprunte mémoire et réduire la taille du code, j’ai « épicé » mon code en utilisant la « curryfication« .
Cela m’a appris un tas de chose et le plus beau cadeau a été de m’intéresser à la programmation fonctionnelle, cela m’a ouvert les yeux sur une myriade de concepts fabuleux. C’est ainsi que je me suis lancé dans l’apprentissage du language Haskell, et j’ai ainsi pu mettre en pratique des concepts qui sont généralement utilisés dans des languages fonctionnels à contribution dans le code PHP, et notamment dans loophp/collection.
De manière implicite, j’ai été plus efficient dans ma manière de programmer, d’utiliser la technique function-first, data-last ou encore de découvrir la programmation tacite (ou point-free-style).
L’utilisation de ces techniques m’ont permis d’être très strict au niveau du typage et ainsi faciliter l’analyse statique du code.
Pol, tu es belge : peux-tu nous parler de la communauté de développeuses et développeurs en Belgique ? Avez-vous l’équivalent de l’AFUP, des occasions de vous réunir ?
En effet, je suis Belge d’origine Italienne et je me considère comme un Européen. C’est probablement mon environnement de travail à la Commission Européenne qui a accentué cette manière de voir les choses. De ce que me souviens je le ressentais déjà comme ça dès mon plus jeune age, mes parents ont bien fait leur travail.
Au commencement de ma carrière, je me suis beaucoup impliqué dans la communauté Drupal pour laquelle je ne contribue plus ou presque plus. J’allais aux quatre coins de la planète pour assister à des conférences et workshops. Tout récemment et pour de multiples raisons, j’ai ré-orienté ma carrière afin de me concentrer sur une utilisation plus *corporate* et professionnelle de PHP, sans Drupal. Je ne regrette pas mon choix, sauf que mes anciens collègues me manquent, surtout en cette période atypique. La Belgique regorge de devs PHP et généralement ils ne sont jamais sans emploi ! Beaucoup de ceux ci travaillent à la Commission Européenne, il y a beaucoup d’activité autour de Drupal. Venant de ces contrées, je les connais un peu près tous et je les salue chaleureusement !
Pour la répartition des genres, le monde du développement semble être un monde d’hommes, les seules développeuses que je connais peuvent se compter sur les doigts d’une main, je les salue bien amicalement par la même occasion !
D’un point de vue strictement personnel, je n’ai jamais senti de malaise de quiconque concernant le genre, j’ai l’impression que si peu de femmes sont présentes à cause d’us et coutumes anciennes. Des changements de mentalités sont encore a faire pour sortir des canevas préconçus du passé. Même si beaucoup d’effort ont été fait, l’eau devra encore couler sous les ponts, pour effacer les préjugés et déconstruire dans certaines têtes que les femmes, tout comme les hommes, peuvent être ce qu’elles veulent et pas uniquement bonnes dans les tâches qu’on leur a toujours assignées depuis la nuit des temps. Et bien évidemment, c’est également vrai pour les hommes qui souhaitent se lancer dans des métiers majoritairement représentés par des femmes tels que les infirmières, puéricultrices et j’en passe.
En ce qui concerne une communauté semblable à l’AFUP, je ne connais que PHP Benelux et j’assiste régulièrement aux réunions. Je dois bien vous avouer que je suis très envieux de l’effervescence et des communautés que je peux voir dans votre pays.
Et pour terminer, il y a environ 6 ans j’ai décidé de me relocaliser et j’ai complètement arrêté de voyager et m’impliquer autant qu’auparavant afin de me consacrer à mes projets de rénovation.
Depuis lors, je reprends tout doucement le pli, d’où ma soumission d’une présentation où je vous remercie déjà de l’avoir choisie, j’ai hâte de vous la présenter.