Envoyé par
Jérôme Lambert
On est d'accord qu'il va falloir utiliser le typage dynamique à bon escient, lorsque cela s'avère vraiment nécessaire (interrop, réflexion).
Perso je crains que ces types dynamiques ne soit privilégiés à d'autres solutions que je trouve plus propre.
Si je reprend l'exemple de la réflection :
1
2
| dynamic obj = quelquechose;
obj.Test(); |
Puisqu'on connait la signature de la méthode, pourquoi ne pas tout simplement faire ceci :
1
2
| UnTypeCommun obj = (UnTypeCommun) quelquechose;
obj.Test(); |
De plus cela peut être complètement sécurisé via l'opérateur
is (ou
instanceof en
Java) :
1
2
3
4
| if (quelquechose is UnTypeCommun) {
UnTypeCommun obj = (UnTypeCommun) quelquechose;
obj.Test();
} |
Dans tous les cas où on connait la méthode a appeler à la compilation, mais qu'on ignore le type de l'objet, je pense personnellement qu'il est préférable de passer par un cast sur le type réel ou un type parent commun.
Envoyé par
Jérôme Lambert
D'ailleurs, Smyley l'a montré dans son exemple, la réflexion n'est pas type safe lorsqu'on joue avec des accès aux méthodes/propriétés/etc via des string. Si tu te trompes => exception.
Oui... sauf que c'est propre à la réflection : on sait très bien que cela peut générer une exception. L'API de reflection est tout sauf sûr
A l'inverse avec les types dynamiques, on se retrouve avec des codes apparemment anodins mais source de problème potentiel :
Un appel de méthode qui échoue ! (ce n'est pas le code de la méthode qui remonte une exception, mais bel et bien l'appel de la méthode). Le problème étant que l'exception peut survenir n'importe où !
Ce n'est que mon avis, mais je ne trouve pas ce mélange de niveau de typage est à utiliser avec des pincettes...
a++
0 |
0 |
).
)
