Choix d'implémentation des types de données issus des octets brutes des librairies C FSV #74

New Issue

florian_briand · 2024-10-03T18:10:13+02:00

florian_briand commented

2024-10-03 18:10:13 +02:00

Deux approches sont possibles pour traiter les types de données issus des données brutes des librairies C.
Chaque approche a (sans-doute) ses avantages et ses inconvénients, mais je n'arrive pas à me décider.

APPROCHE 1 - Chaque champ est un type générique

pub struct SVComponentsConfig {
    pub id: NumericString,
    pub description: AlphaNumericString,
    pub version: AlphaNumericString,
} /*
SVComponentsConfig {
    id: NumericString(
        "151",
    ),
    description: AlphaNumericString(
        "IDENTIFIANT UNIQUE DU POSTE",
    ),
    version: AlphaNumericString(
        "269fc7eb-1d85-4793-b70e-371c38f91634",
    ),
},

/// Usage :
/// let component_config = get_components_config();
/// let component_description: String = component_config.description.0;
*/

Avantages

Simplicité : moins de conversions, moins de code à écrire, moins d'indirections

Inconvénients

Moins de garanties sémantiques : tous les champs AlphaNumericString sont du même type, rien ne différencie structurellement la description de la version dans l'exemple précédent
Moins de possibilités de contrôle / formatage spécifiques

APPROCHE 2 - Chaque champ est un type spécifique

pub struct SVComponentsConfig {
    pub id: ComponentID,
    pub description: ComponentDescription,
    pub version: ComponentVersion,
} /*
SVComponentsConfig {
    id: ComponentID(
        NumericString(
            "151",
        ),
    ),
    description: ComponentDescription(
        AlphaNumericString(
            "IDENTIFIANT UNIQUE DU POSTE",
        ),
    ),
    version: ComponentVersion(
        AlphaNumericString(
            "269fc7eb-1d85-4793-b70e-371c38f91634",
        ),
    ),
},

/// Usage :
/// let component_config = get_components_config();
/// let component_description: String = component_config.description.0.0;
*/

Avantages

Côté typage, on gagne en "clarté technique" : pas d'ambiguïté, quand on manipule une "ComponentDescription", ça n'est pas une "ComponentVersion"
Ça permet l'implémentation de règles spécifiques de taille, de composition, de conversion
Ça devrait aussi faciliter l'écriture de données, pour les cas où on doit faire de l'encodage de données en binaire pour les envoyer sur ls cartes (ça arrive dans quelques situations), car chaque champ peut alors porter "en lui" les règles de binarisation

Inconvénients

Beaucoup de code boilerplate de déclaration de types de champs. Exemple de déclaration d'un champ :

#[deku_derive(DekuRead)]
#[derive(Debug, PartialEq)]
pub struct ComponentDescription(pub AlphaNumericString);

Plus de lourdeur à l'utilisation, à cause de la double encapsulation de la donnée : description.0.0

Deux approches sont possibles pour traiter les types de données issus des données brutes des librairies C. Chaque approche a (sans-doute) ses avantages et ses inconvénients, mais je n'arrive pas à me décider. ## APPROCHE 1 - Chaque champ est un type générique ```rust pub struct SVComponentsConfig { pub id: NumericString, pub description: AlphaNumericString, pub version: AlphaNumericString, } /* SVComponentsConfig { id: NumericString( "151", ), description: AlphaNumericString( "IDENTIFIANT UNIQUE DU POSTE", ), version: AlphaNumericString( "269fc7eb-1d85-4793-b70e-371c38f91634", ), }, /// Usage : /// let component_config = get_components_config(); /// let component_description: String = component_config.description.0; */ ``` ### Avantages - Simplicité : moins de conversions, moins de code à écrire, moins d'indirections ### Inconvénients - Moins de garanties sémantiques : tous les champs AlphaNumericString sont du même type, rien ne différencie structurellement la `description` de la `version` dans l'exemple précédent - Moins de possibilités de contrôle / formatage spécifiques ## APPROCHE 2 - Chaque champ est un type spécifique ```rust pub struct SVComponentsConfig { pub id: ComponentID, pub description: ComponentDescription, pub version: ComponentVersion, } /* SVComponentsConfig { id: ComponentID( NumericString( "151", ), ), description: ComponentDescription( AlphaNumericString( "IDENTIFIANT UNIQUE DU POSTE", ), ), version: ComponentVersion( AlphaNumericString( "269fc7eb-1d85-4793-b70e-371c38f91634", ), ), }, /// Usage : /// let component_config = get_components_config(); /// let component_description: String = component_config.description.0.0; */ ``` ### Avantages - Côté typage, on gagne en "clarté technique" : pas d'ambiguïté, quand on manipule une "ComponentDescription", ça n'est pas une "ComponentVersion" - Ça permet l'implémentation de règles spécifiques de taille, de composition, de conversion - Ça devrait aussi faciliter l'écriture de données, pour les cas où on doit faire de l'encodage de données en binaire pour les envoyer sur ls cartes (ça arrive dans quelques situations), car chaque champ peut alors porter "en lui" les règles de binarisation ### Inconvénients - Beaucoup de code boilerplate de déclaration de types de champs. Exemple de déclaration d'un champ : ```rust #[deku_derive(DekuRead)] #[derive(Debug, PartialEq)] pub struct ComponentDescription(pub AlphaNumericString); ``` - Plus de lourdeur à l'utilisation, à cause de la double encapsulation de la donnée : `description.0.0`

florian_briand added the

question

label 2024-10-03 18:10:13 +02:00

florian_briand self-assigned this 2024-10-03 18:10:13 +02:00

florian_briand referenced this issue

2024-10-03 23:42:44 +02:00

Implémentation du parsing complet des données issues de SSV_LireConfig parsing, en utilisant deku pour une approche déclarative des règles de parsing binaire #75

kosssi commented

2024-10-10 15:23:20 +02:00

Je partirai pour l'instant sur l'approche 1 pour nous simplifier la vie. Nous pourrons dans tous les cas, si nous en voyons le besoin repasser à une version plus complexe pour des champs spécifiques.

Sign in to join this conversation.