Discussion :

[Jérôme Lambert]

Bonjour à tous,

Je vous présente mon tout dernier article qui vous permettra de découvrir ce que la future version de C# nous réserve :

C'est lors de la Microsoft PDC 2008 (Professional Developer Conference) que Anders Hejlsberg - père spirituel de C# - a dévoilé le voile sur la prochaine version de son langage : C# 4.0.
Au cours de cet article, nous ferons un tour d'horizon des nouveautés qui nous attendent pour cette nouvelle version du langage.

Lien de l'article : http://jlambert.developpez.com/tutor...eautescsharp4/

Bonne lecture à tous

[adiGuba]

Très intérressant !



Par contre, en tant que développeurs Java, certaines de ces fonctionnalités me font un peu frémir :

• Les types dynamiques sont plutôt l'apanage des langages de script...
  Cela génère un code peu sécurisé (le compilateur ne peut plus faire aucune vérification).
  
  Si je comprend tout à fait l'intérêt d'intégrer cela dans le runtime pour mieux supporter les langages de script (ce sera d'ailleurs également le cas dans le bytecode Java 7 avec la JSR 292), j'emet quand même de gros doute quand à l'intérêt de cela dans un langage fortement typé comme C# !
  
  
• Les paramètres nommés, qui impliquent que les noms des paramètres soit intégrés dans la signature de la méthode.
  
  La moindre modification sur un nom de paramètre pourrait alors casser du code existant

Sinon en ce qui concerne les paramètres optionnels, je trouve cela plutôt utile en C++ : cela permet d'éviter de multiplier les définitions de méthodes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static void MaMethode(string s, int i, bool b)
{
	Console.WriteLine("s = {0}, i = {1}, b = {2}", s, i, b);
}
 
public static void MaMethode(string s, int i)
{
	MaMethode(s, i, false);
}
 
public static void MaMethode(string s)
{
	MaMethode(s, 10);
}

Par contre je n'ai pas trop d'expérience là dessus (très peu de C++), et je me demande si cela ne peut pas posé quelques petits conflit dans certain cas un peu tordu...





Enfin en ce qui concerne la covariance/contravariance des génériques, je confirme que c'est très pratique pour écrire du code encore plus "générique", même si cela complique encore un peu le code




a++

[Jérôme Lambert]

Pour les pramètres nommés et optionnels, ça va de paire avec le typage dynamique lorsqu'on fait de l'interrop pour accéder, par exemple, à des méthodes Excel/Word qui ont une étendue interminable de paramètres optionnels.

Avec C# 3.0 et les versions précédentes, on est obligé de définir une valeur pour chacun des paramètres même si on en a rien à faire. Avec C# 4.0, ce sera bientôt un mauvais souvenir.

[adiGuba]

Je suis d'accord sur le fait que cela peut avoir un coté intéressant et utile



Mais les types dynamiques reviennent à utiliser un typage faible dans un langage fortement typé

Le cast est peut-être pas très joli, mais il a un intérêt : c'est comme un warning qui dit "attention je change le type", et qui signale donc un problème potentiel.
Mais si l'opération réussi le reste du code est bien typesafe.

Avec les types dynamiques le cast disparait mais c'est l'ensemble du code qui est potentiellement erroné !
Le compilateur ne pourra pas signaler les éventuels problème sur un appel de méthode erroné


a++

[smyley]

Personnellement l'utilité principale que je vois aux types dynamiques c'est lorsque l'on se bat avec de la réflection. Par exemple, la ligne

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
object obj = quelquechose;
Type bidule = obj.GetType();
MethodInfo m = bidule.GetMethod("Test",...)
m.Invoke(obj, ...)

deviendrais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
dynamic obj = quelquechose;
obj.Test();

Et donc histoires d'interop et autres on va vite sentir la différence. Par contre c'est sur c'est donner plus de pouvoirs aux développeurs et il faudra faire attention de ne pas l'utiliser n'importe comment.

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

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.