Path: ...!newsreader4.netcologne.de!news.netcologne.de!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: =?UTF-8?B?U3TDqXBoYW5lIFJpdmnDqHJl?= <stef@genesix.org>
Newsgroups: fr.comp.lang.ada
Subject: =?UTF-8?Q?Re=3A_Question_structure_de_donn=C3=A9es?=
Date: Mon, 9 Oct 2023 09:43:08 +0200
Organization: La Maison
Lines: 102
Message-ID: <ug0aud$3negc$2@dont-email.me>
References: <ufcalc$i3v$1@rasp.pasdenom.info> <ufr2f8$28d89$1@dont-email.me>
 <ufshr8$p80$1@rasp.pasdenom.info> <uftqo8$30fpk$1@dont-email.me>
 <ufunr1$q7m$2@rasp.pasdenom.info>
Reply-To: stef@genesix.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 9 Oct 2023 07:43:09 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f61c4256a46730a61454888e0be9692f";
	logging-data="3914252"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+A9zffcQK2VEefrhFyig4Ia7oxfz5POfI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:sk+RDBkc2bEpAKeB5M+0tVTRD7A=
In-Reply-To: <ufunr1$q7m$2@rasp.pasdenom.info>
Content-Language: fr
Bytes: 5069

>> ================================================
>>
>> 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