Discussion :

[Laurent Dardenne]

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') .

[tomlev]

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

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

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.

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 ?

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

[Laurent Dardenne]

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.

Par exemple un paramètre bool dontThrowOnMissingValue pour ne pas lever d'exception...

Cette simplicité me plait, laisser l'appelant décider du comportement.

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.

Arf, j'avais pas pensé à ce cas là

Bah, c'est la lecture la doc de GetProperty que m'a fait l'ajouter...

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.

mais bon, c'est toujours une beta

Ouai, elle rempli son rôle

[tomlev]

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

[Laurent Dardenne]

Merci