Re: Question structure de données

================================================
>
Dans l'ads j'ai :
>
---------------------------------
type Schema_Line is record
       Command : Schema_Command;
       Name : String;
       Attribute : String;
       Comment : String;
    end record;
>

Ah, tiens, je croyais qu'on ne peux pas mettre des String non bornées dans un record.

"techniquement", c'est en fait un pointeur car... Oublié de préciser que dans ce contexte, les premières lignes de v22.ads sont :
    with UXStrings; use UXStrings;
    subtype String is UXString;
(UXString étant fondé sur de l'Unbounded_String à 4 octets)
C'est sale mais tellement bon.
Comme évoqué lors d'une discussion sur la ml Ada-France avec Jean-Pierre, qui me disait fort justement :
C'est une mauvaise idée que d'appeler un type utilisateur "String", ou de n'importe quel autre nom défini dans Standard. Comme Standard est implicitement le parent de toutes les autres unités, les types y sont toujours directement visibles, et préférés aux types synonymes que l'on pourrait croire directement visibles par une clause "use". Ca crée souvent des confusions, et ça peut jouer dans ton cas.
J'argumentais alors :
Oui, tu as raison bien sûr.
L'idée de Pascal (Blady) est de rendre Gnoga compatible UTF-8 (avec UXString) sans reprendre toutes les sources. Je trouve que le résultat est si efficace que j'ai adopté sa technique pour notre nouveau framework v22, qui utilise Gnoga. Le portage v20 > v22 avec cette astuce a profondément simplifié le code et sa mise en œuvre.
Je sais bien que ton conseil est le bon. Voici ma justification foireuse : en pratique on ne manipule plus qu'un unique type String, UTF-8, Unbounded, avec une API standard et ça règle une fois pour toute le pb des strings dans Ada. Le framework v22 masque tout. L'utilisateur est dans le confort.
C'est non conforme aux bonnes pratiques et sous-optimal du coté de la mémoire. En pratique, ça impacte peu coté ram (v22 implémente des goodies Gnatcoll qui permettent de regarder ça de près) et je n'ai pas constaté d'effet de bord, hormis le cas qui fait l'objet de ce message.
Aurais-je du utiliser le type de base UXString ? Certainement. Mais avec Gnoga utilisant ce subtype String, je reste uniforme. Et je ne voulais pas non plus forker Gnoga pour remettre partout le type UXString. C'est typiquement un compromis...
J'obtenais l'absolution de Jean-Pierre :
OK, je comprends. Du moment que la décision de conception est justifiée...
Précisions (autre extrait) :
On peut bien sûr continuer d'accéder à l'ex type prédéfini String par Standard.String.
En passant, UXString v3 est un bonheur qui m'a permis de porter sans aucun effort un framework complet vers l'UTF-8. L'API est standard, on a l'opérateur de concaténation &¹ et on a plus besoin d'initialiser les strings littérales avec l'opérateur +. L'usage est donc transparent et ça rend la manip de strings UTF-8 aussi naturelle en Ada qu'en Python (désolé pour la comparaison).
C'est aussi idéal quand on s'interface avec des DB en UTF-8 et, bien sûr, c'était le propos initial, quand on dev pour le Web. C'est stable, véloce, compatible Zanyblue (internationalisation). La conso mémoire résultante est insignifiante en pratique. Merci Pascal :). https://github.com/Blady-Com/UXStrings
¹ On est loin de certains packages de Strings UTF-8 à l'API non conventionnelle et sans l'opérateur de concaténation &.
Pour ma part, UXStrings devrait être dans le RM et Pascal décoré de la plus haute distinction Ada : la médaille "In strong typing we trust" ;)
--
Stéphane Rivière
Ile d'Oléron - France