1. #1
    Rédacteur


    Profil pro
    Inscrit en
    janvier 2003
    Messages
    6 834
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 6 834
    Points : 15 151
    Points
    15 151
    Billets dans le blog
    1

    Par défaut À propos de la classe StringTemplate

    Après qq tests j'ai qq questions à propos de la classe Developpez.Dotnet.Text.StringTemplate.
    Les classes c# suivantes peuvent générer qq erreurs :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    using System;
    namespace Tstdvp
    {
     public class TypeA {     
      public virtual int Height { get; set; } 
     }  
     
     public class TypeB : TypeA {  
      public new String Height { get; set; } 
     }  
     
     public class Class1 : TypeB {         
     }  
       public  class MyClass 
         {
            public int x;
            public readonly int y = 25; // Initialize a readonly field
            public readonly int z;
     
            public int RO { 
              set
              {
                  x = value;
              }
            }
     
            public int X { 
              get
              {
                  return x ;
              }
              set
              {
                  x = value;
              }
            }
     
            public MyClass() 
            {
               z = 24;   // Initialize a readonly instance field
            }
     
            public MyClass(int p1, int p2, int p3) 
            {
               x = p1; 
               y = p2; 
               z = p3;
            }
         }
      }
    Ma première question concerne la documentation qui ne précise pas pour l'extrait de la phrase suivante "en utilisant des noms plutôt que des numéros pour les placeholders ", si le terme de nom concerne uniquement un nom de propriété ou un nom de champ ou devrait concerner les deux.

    Le code indique qu'il s'agit uniquement de propriété, du coup je ne sais pas si c'est un choix de conception (implicite/non documenté) ou une erreur de codage (appel à getproperty ET appel à getfield).

    Si j'utilise les membres x,y,z de la classe MyClass la chaine retournée est égale au template, il n'y a aucun remplacement et aucune exception n'est déclenchée.
    Si j'utilise son membre RO j'obtiens une exception (System.ArgumentException: La méthode Property Get est introuvable).

    Si j'utilise le membre Height de la classe TypeB j'obtiens une exception (System.Reflection.AmbiguousMatchException: Correspondance ambiguë trouvé).

    Autant les deux derniers comportements ne me gênent pas plus que ça,(je sais ce qui ne 'passe' pas) autant le premier comportement m'embarasse, car rien ne me dit que mon code est faux (tout 'passe') .

  2. #2
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Citation Envoyé par Laurent Dardenne Voir le message
    Ma première question concerne la documentation qui ne précise pas pour l'extrait de la phrase suivante "en utilisant des noms plutôt que des numéros pour les placeholders ", si le terme de nom concerne uniquement un nom de propriété ou un nom de champ ou devrait concerner les deux.

    Le code indique qu'il s'agit uniquement de propriété, du coup je ne sais pas si c'est un choix de conception (implicite/non documenté) ou une erreur de codage (appel à getproperty ET appel à getfield).
    Effectivement, ça ne gère que les propriétés. Je me suis pas vraiment posé la question sur le moment, mais c'est vrai qu'on pourrait aussi gérer les champs. Je vais modifier le code en ce sens, et préciser un peu la doc

    Citation Envoyé par Laurent Dardenne Voir le message
    Si j'utilise les membres x,y,z de la classe MyClass la chaine retournée est égale au template, il n'y a aucun remplacement et aucune exception n'est déclenchée.
    C'est un choix, si aucune propriété correspondant au placeholder n'est trouvée, je laisse le placeholder tel quel. Après, je sais pas si c'est judicieux... je me rappelle avoir pas mal hésité, mais je sais plus quels étaient les arguments qui m'avaient décidé à faire comme ça . Dans un sens, c'est vrai que pour rester cohérent avec le comportement de String.Format, il faudrait lever une exception...

    En tous cas si tu as des arguments dans un sens ou dans l'autre, n'hésite pas à les donner

    Sinon, pour pas se prendre la tête, on pourrait aussi rendre ça optionnel. Par exemple un paramètre bool dontThrowOnMissingValue pour ne pas lever d'exception...


    Citation Envoyé par Laurent Dardenne Voir le message
    Si j'utilise son membre RO j'obtiens une exception (System.ArgumentException: La méthode Property Get est introuvable).
    Ben les propriétés write-only, ça court pas les rues... j'en ai jamais vu un seul exemple dans du code "réel". Mais effectivement, ce serait pas compliqué de gérer ce cas pour au moins éviter l'exception. Je vais ajouter un test sur CanRead.

    Citation Envoyé par Laurent Dardenne Voir le message
    Si j'utilise le membre Height de la classe TypeB j'obtiens une exception (System.Reflection.AmbiguousMatchException: Correspondance ambiguë trouvé).
    Arf, j'avais pas pensé à ce cas là

    Je sais pas trop quelle serait la meilleure façon de gérer ça... ce qui correspont le mieux au comportement "attendu" est sans doute de prendre le membre le plus spécifique, donc le membre déclaré dans la classe plutôt que le membre hérité. En gros, on pourrait prendre, par ordre de priorité :

    - propriété déclarée dans la classe (BindingFlags.DeclaredOnly)
    - champ déclaré dans la classe
    - propriété héritée
    - champ hérité

    Qu'en penses-tu ?

    Citation Envoyé par Laurent Dardenne Voir le message
    Autant les deux derniers comportements ne me gênent pas plus que ça,(je sais ce qui ne 'passe' pas) autant le premier comportement m'embarasse, car rien ne me dit que mon code est faux (tout 'passe') .
    Effectivement, vu sous cet angle il vaudrait mieux lever une exception. Ce qui m'embête, c'est que si je change ça, c'est potentiellement un breaking change... mais bon, c'est toujours une beta, et c'est pas comme si y avait des milliers d'utilisateurs .


    Merci pour ton retour en tous cas

  3. #3
    Rédacteur


    Profil pro
    Inscrit en
    janvier 2003
    Messages
    6 834
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 6 834
    Points : 15 151
    Points
    15 151
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par tomlev Voir le message
    Dans un sens, c'est vrai que pour rester cohérent avec le comportement de String.Format, il faudrait lever une exception...
    Pour le moment, je ne vois que ça comme argument.
    Citation Envoyé par tomlev Voir le message
    Par exemple un paramètre bool dontThrowOnMissingValue pour ne pas lever d'exception...
    Cette simplicité me plait, laisser l'appelant décider du comportement.
    Citation Envoyé par tomlev Voir le message
    j'en ai jamais vu un seul exemple dans du code "réel".
    Oui, le code n'a aucun sens sauf celui de mettre en évidence les cas d'erreurs.
    Citation Envoyé par tomlev Voir le message
    Arf, j'avais pas pensé à ce cas là
    Bah, c'est la lecture la doc de GetProperty que m'a fait l'ajouter...
    Citation Envoyé par tomlev Voir le message
    Qu'en penses-tu ?
    Que j'aurais procéder de la même manière, je pense que la fréquence d'usage d'une propriété est effectivement plus grande que celle d'un champ.
    Citation Envoyé par tomlev Voir le message
    mais bon, c'est toujours une beta
    Ouai, elle rempli son rôle

  4. #4
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 836
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 836
    Points : 40 629
    Points
    40 629

    Par défaut

    Bon, c'est adjugé

    J'ai modifié et ajouté quelques T.U., ça a l'air de bien se passer. Ce sera dans la prochaine version

  5. #5
    Rédacteur


    Profil pro
    Inscrit en
    janvier 2003
    Messages
    6 834
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2003
    Messages : 6 834
    Points : 15 151
    Points
    15 151
    Billets dans le blog
    1

    Par défaut

    Merci

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. A propos de la Classe Scanner
    Par tolliob dans le forum Langage
    Réponses: 5
    Dernier message: 10/03/2014, 17h33
  2. à propos de la Classe clistctrl
    Par yann458 dans le forum Windows
    Réponses: 0
    Dernier message: 20/10/2011, 14h21
  3. Réponses: 1
    Dernier message: 05/04/2008, 16h13
  4. A propos des classes abstraites
    Par OhLiberty dans le forum C++
    Réponses: 5
    Dernier message: 15/09/2006, 19h11
  5. A propos de la classe ThreadLocal
    Par santana2006 dans le forum Langage
    Réponses: 5
    Dernier message: 25/07/2006, 19h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo