<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">Le 17/03/2024 à 18:45, Sébastien
      Feugère a écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:07135DC6-674E-44B7-9A00-BC8759682F79@feugere.net">
      <pre class="moz-quote-pre" wrap="">
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">* utilisation de corinna pour remplacer les hashmap par des objets dans le code
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
Par curiosité, et parce que je n’ai pas trouvé de discussion sur GitHub sur ce sujet: quel est votre plan pour accomplir cela? En effet, « Corinna » est une spécification, et donc, son implémentation à ce jour, peut être réalisée de deux façons:

- 1) utilisation d’un Perl &gt;= à 5.38, où apparaît une implémentation expérimentale et incomplète de Corinna avec les mots clé class, method, field etc. Il faut donc en amont s’assurer que openfoodfact-server est compatible avec cette version de Perl (utilise 5.32 à ce jour si mes informations sont correctes ?). 5.38 serait disponible avec Debian Trixie(testing). La dernière version stable de Debian fournit quand à elle Perl 5.36, sans la syntax class, donc. D’autres solutions telles que perlbrew sont envisageables pour choisir sa version de Perl indépendamment de Debian, mais cela ne semble pas être la méthode retenue d’après ce qui est décrit dans le Dockerfile de openfoodfact-server ?
- 2) utilisation du module Object::Pad (utilisable sur Perl &gt;= 5.26), qui fournit l’implementation la plus aboutie de Corinna, mais qui fournit moins de garanties quant à la stabilité de son API (disons que c’est de l’expérimental++, mais qui a de fortes chances de se retrouver dans le Perl « core » quand même après discussions avec p5p et autres). Très bien pour une expérimentation rapide, sans avoir la dépendance « upgrade Debian » en épée de Damoclès.

La préparation nécessaires en amont est assez différente selon que l’on veuille « juste expérimenter » avec ces fonctionnalités ou bien que l’on pense à préparer du code pour la production et le futur, etc.</pre>
    </blockquote>
    <p>Hello, </p>
    <p>Clairement l'idée est plutôt d'aller sur du code qui parte
      rapidement en production.<br>
    </p>
    <p>je pense que l'on partira plutôt sur Perl &gt;= 5.38. Après c'est
      à l'équipe qui prendra le sujet en main de décider :-)</p>
    Actuellement on est en Perl 5.32 donc j'imagine que la montée de
    version sera plutôt facile en soit (peut-être en partant de l'<a
      href="https://hub.docker.com/_/perl">image Docker adéquat</a>, au
    moins pour les tests).
    <p>En production (qui est une installe LXC/container proxmox), on
      est encore sur debian bullseye, est-il difficile d'installer une
      version de perl différente de celle officielle ? (<a
href="https://github.com/perl/docker-perl/blob/eda25fcceccf8e178bf1e41ce4d4196ab3e8f8af/5.038.002-main-bookworm/Dockerfile">le
        dockerfile de l'image ci-dessus</a> peut servir d'exemple)<br>
    </p>
    <p>++Alex<br>
    </p>
    <br>
    <div id="grammalecte_menu_main_button_shadow_host"
      style="width: 0px; height: 0px;"></div>
  </body>
</html>