Discussion :

[metalsephiroth]

Bonjour à tous,

J'aurai voulu connaitre l'utilité du mot clef params dont voici la page de documentation sur la MSDN.

http://msdn.microsoft.com/fr-fr/libr...=vs.80%29.aspx

J'avoue me creuser les méninges pour en trouver une utilité mais je n'en vois aucune.

Merci

[kzrystof]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public int Add(params int[] ops)
{
    int result = 0;
 
    for(int i=0; i<ops.Length; i++)
         result += ops[i];
 
    return result;
}
 
int r1 = Add(1,2,3,4);
int r2 = Add(1);

Un exemple vaut mille mots J'espère

[metalsephiroth]

l'équivalent aurait probablement été

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
public int Add(int[] ops)
{
    int result = 0;
 
    for(int i=0; i<ops.Length; i++)
         result += ops[i];
 
    return result;
}
 
int r1 = Add(new int[]{1,2,3,4});
int r2 = Add(new int[]{1});

Je suis tout à fait d'accord pour l'utilisation que j'ai bien compris.
Pourquoi faire compliqué quand le code ci-dessus produit le même résultat ?

Ce mot clef a quand même une utilité j'ose espérer ??

[kzrystof]

Si params n'existait pas, voici ce que tu aurais à faire:

Code :

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

string.Format("{0} {1}", new string[] { "Param1", "Param2"});

au lieu de :

Code :

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

string.Format("{0} {1}", "Param1" "Param2");

Son utilité ? Rendre le code plus propre.

[cs_ntd]

Tout a fait.

La plateforme .NET, et plus particulièrement le C# adore () les sucres syntaxiques.

Dans le meme ordre d'idée, tu pourrais poser les questions :
- A quoi servent les Propriétés ? (get{}, set{})
- A quoi servent les Lamdas Expressions ?
- Yen a surement d'autres...

Bin la réponse est simple : diminuer le nombre de lignes de code, diminuer la dépendence, faciliter la lecture du code, rendre les choses plus intuitives...

Donc bien sur qu'on peut faire autrement qu'utiliser "params", bien que ca facilite les choses. De meme qu'on est pas obliger de faire de la prog objet, et ce genre de trucs qui facilite le codage, on se débrouillait très bien avant avec le C

(Mais meme en C, on avait déjà le droit de préciser des méthodes avec un nombre d'arguments variable... la plus célébre est sans doute 'printf').

[Bluedeep]

La plateforme .NET, et plus particulièrement le C# adore () les sucres syntaxiques.

Dans le meme ordre d'idée, tu pourrais poser les questions :
- A quoi servent les Propriétés ? (get{}, set{})

Ce n'est pas vraiment ce qui me vient à l'esprit en premier.
Je dirais même que considérer les propriétés comme un "syntax suger" me parait une vision grossière : leur absence aurait des impacts lourds sur les processus de serialisation/deserialisation (hors sérialisation binaire). En effet, il faudrait les remplacer par des accesseurs (façon java) ou par des membres (violation du principe d'encapsulation et incapacité de valider les valeurs.
Les accesseurs ne sont que des méthodes et ne peuvent participer au processus de sérialisation; l'affectation de valeurs à des membres ne permet pas d'exécuter d'instructions.

Donc, les propriétés sont tout sauf un "syntax sugar"

Le "vrai" "syntax sugar" qui vient à l'esprit en premier, ce sont les méthodes d'extensions.

[Bluedeep]

Je suis tout à fait d'accord pour l'utilisation que j'ai bien compris.
Pourquoi faire compliqué quand le code ci-dessus produit le même résultat ?

Ce mot clef a quand même une utilité j'ose espérer ??

J'ai un peu de mal à comprendre ta réponse :

Qu'est qui est plus compliqué ?

Ca :

Code :

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

1
2
int r1 = Add(1,2,3,4);
int r2 = Add(1);

ou ça :

Code :

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

1
2
int r1 = Add(new int[]{1,2,3,4});
int r2 = Add(new int[]{1});

Que ce soit du point de vue la lisibilité ou de la complication, pour moi, il n'y a pas photo, la première solution l'emporte largement.

Sans même parler de la "lisibilité sémantique" (désolé pour ce barbarisme) :

Quand je lis

Code :

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

int r2 = Add(new int[]{1})

Je m'interroge clairement sur la signification de cet appel; alors que :

Code :

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

int r2 = Add(1);

ne soulève aucune interrogation sur sa signification.

[metalsephiroth]

Très bien je comprends son utilité ainsi.
Merci pour vos réponses.

Quand je parlais d'utilité, je pensais que ce mot clé pouvait être une solution élégante pour résoudre différents problèmes algorithmiques.

Connaissez-vous beaucoup d'autres sucres syntaxiques ?

[Nathanael Marchand]

Il y'en a plusieurs:

• les lambda expressions
• la possibilité de mettre get;set; dans une propriété sans le backing field
• les méthode d'extension (ce qui ammène LINQ notamment)
• la possibilité d'initialiser les propriétés lors de l'appel du constructeur

[DonQuiche]

Linq !

Code :

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

1
2
3
4
5
var boulotIdéal = boulots.Where(x => x.Distance < 20 && !x.TachesAFaire.Any(t => t.Interest < 0.3 || t.Langage == "php"))
   .Max(x => 
      0.3 * x.Employes.Count(employe => employe.IsASexBomb) / (double)x.Employees.Length
      + 0.4 * x.TachesAFaire.Average(t => t.Interest)
      + 0.6 * x.BrouzoufsParAn / SalaireActuel);

40 lignes de code résumées en 4, ça fait du bon sucre syntaxique. Et je recopie les smileys si je veux.

Sinon, on pourrait aussi citer :
* L'opérateur ternaire : condition ? vrai : faux
* Le coalescence operator : x ?? y (équivaut à x != null ? x : y)
* var : l'inférence de types à la compilation, c'est quand même choupi.
* Les types anonymes : var x = { Name = "John", FamilyName = "Doe" }

[ctxnop]

Linq !

Code :

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

1
2
3
4
5
var boulotIdéal = boulots.Where(x => x.Distance < 20 && !x.TachesAFaire.Any(t => t.Interest < 0.3 || t.Langage == "php"))
   .Max(x => 
      0.3 * x.Employes.Count(employe => employe.IsASexBomb) / (double)x.Employees.Length
      + 0.4 * x.TachesAFaire.Average(t => t.Interest)
      + 0.6 * x.BrouzoufsParAn / SalaireActuel);

40 lignes de code résumées en 4, ça fait du bon sucre syntaxique. Et je recopie les smileys si je veux.

Mouais, y'a encore plus court et sans sucre syntaxique :

Code :

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

1
2
 
var BoulotIdeal = null;

Et voila

Pour être plus sérieux, je suis vraiment pas fan de la majorité des sucres syntaxiques.

Genre, perso, je trouve LinQ beaucoup moins lisible (ca c'est surtout une question de gout), j'hésite toujours 10 minutes pour comprendre ce que fait x => x.Distance < 20.

Sans compter qu'une méthode contenant du LinQ ou des expression lambas, ou des méthodes anonymes, ne peuvent pas être modifiée pendant l'exécution en debug (Edit&Continue).
En prime, si l'expression est pas bonne, c'est indébogable (on ne peut pas inspecter les valeurs des variables).
C'est sur que c'est puissant et ca permet de faire des parcourt de liste en très peu de code, mais je trouve les inconvénients supérieurs aux avantages.

Idem, les variables var, c'est pratiques parce que tu peux changer pleins de choses sans problème, genre tu fais une méthode qui retourne un int, tu stock ce retour comme ceci var value = MaMethode();, et si demain tu change MaMethode pour que ca retourne un Double, ca passera a la compilation sans rien changer (ce que je trouve d'ailleurs très dangereux car selon ce qui est fait avec value le comportement peut changer, alors que si ca avait été typé ca t'aurais forcé a revenir sur la déclaration de value et réfléchir à pourquoi c'était un int).
Sans compter que vu que le type est pas connu au moment où tu code, quand tu reprend un code quelques jours plus tard t'es obligé de chercher ce que tu as bien pu mettre dans cette variable pour savoir de quel type elle est. Si en plus elle est noyé dans un super gros code bien long et complexe, bonjour les maux de têtes.

Donc le suce syntaxique quand il n'y a que des avantages, ok, sinon ....

RAPPEL : c'est un avis personnel, les gouts et les couleurs ...
Chacun fait ce qu'il veut.

[Nathanael Marchand]

Mouais, y'a encore plus court et sans sucre syntaxique :

Code :

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

1
2
 
var BoulotIdeal = null;

Et voila

Tutututu! C'est plutôt Exception: Sequence contains no element

En prime, si l'expression est pas bonne, c'est indébogable (on ne peut pas inspecter les valeurs des variables).

Tutututu! Sur Visual Studio 2010 et .NET4, si ca pète, ca s'arrête à l'itération qui pète et tu connais la valeur problèmatique.

Apres effectivement je ne rentrerai pas dans le débat des var car comme tu dis, les gouts et les couleurs...

[DonQuiche]

Idem, deux petites remarques :
* Je suis passé au VS 2010 récemment et, hier, je me suis retrouvé avec le débogueur au sein d'un lambda en sortant d'une méthode en pas-à-pas. Donc il faudrait que je teste, un breakpoint fonctionne peut-être désormais.
* Pour var, on peut aisément savoir à quel type ça correspond, c'est écrit dans la tooltip si on place la souris au-dessus du var.

Après, en effet, les goûts et les couleurs...

[Bluedeep]

* var : l'inférence de types à la compilation, c'est quand même choupi.

Attention : là encore var n'est pas un syntax sugar.

En effet, dans le cas de certaines requêtes Linq, le type retourné n'existe pas et doit être construit "at compile time" (select X.p1, X.p2 ...) ce qui empêche un typage "classique" et var a été introduit pour répondre à ce besoin spécifique. (type résolu à la compilation mais non nommé).

A ce compte là, tout langage au dessus du C est un "syntax sugar"

[Nathanael Marchand]

Le for, foreach et while ne sont que du syntaxic sugar du goto

[ctxnop]

Tutututu! Sur Visual Studio 2010 et .NET4, si ca pète, ca s'arrête à l'itération qui pète et tu connais la valeur problèmatique.

A condition que ca pète. J'avais plutôt en tête le problème fréquent de s'être gauffré dans la condition (genre inversé le > et le <), ce qui reste tout a fait valable, donc ca pète pas, mais le résultat est pas celui que tu attendais, bah la tu galère pour trouver ce qui va pas car évidemment ca ne saute pas aux yeux.

Et oui, comme dit Bluedeep, var n'est pas vraiment un sucre syntaxique du fait qu'il est nécessaire dans certaines constructions de LinQ (bien que si on considère LinQ comme du sucre syntaxique, on puisse y mettre var aussi dont l'utilité réelle n'est présente que dans le cadre de LinQ).
Cependant, comme toujours, quand il y a une syntaxe "plus simple" introduite pour répondre a un besoin précis, elle est utilisé hors contexte. Ainsi on voit de plus en plus de code en C# qui typent tout en var (ou presque) sans la moindre nécessite. Surement par flemme d'écrire des noms de types a rallonge.

Pour le coup du type détecté dans la tooltip, c'est vrai pour Visual Studio, mais pour les autres IDEs/éditeurs de texte ?
Je suis de ceux qui pensent qu'un code doit être simple a lire, sans avoir besoin d'un outil spécifique, il devrait être facile a lire même avec un notepad (bon, au moins avec la coloration syntaxique, faut pas déconner non plus).

La raison est simple, je n'ai pas toujours Visual Studio sous la main, je couche souvent des bout de code a gauche a droite dans des notepad++ ou équivalent, pour une utilisation future. Ou quand j'ai un bug dans un soft je regarde vit fait avec un éditeur simple pour voir si je ne trouve pas directement l'erreur comme ca. Mais le fait est que seuls ceux qui sont concernés par ces problématiques ont tendance a être contre ces pratiques qui simplifient l'écriture mais rendent la lecture plus difficile sans l'outil adapté.

[cs_ntd]

Je dirais même que considérer les propriétés comme un "syntax suger" me parait une vision grossière.

Pour moi c'est un sucre syntaxique dans la mesure ou après la compilation, il n'y a plus de Property qui existent. Ou disons qu'elles existent en tant que référence vers des getters, setters Get[Property Name] (la meme pour si tu a le champs 'Set'). Ces méthodes sont crées a la compilation.

Donc au final, il n'y a pas vraiment (aucune) différence a l'exécution, dans tous les cas, si tu utilise une property, ton code va appeler une méthode de la classe.
Après, bien sur que c'est mieux au niveau de l'écriture du code, mais c'est justement le but d'un "syntx sugar".

[ctxnop]

Pour moi c'est un sucre syntaxique dans la mesure ou après la compilation, il n'y a plus de Property qui existent. Ou disons qu'elles existent en tant que référence vers des getters, setters Get[Property Name] (la meme pour si tu a le champs 'Set'). Ces méthodes sont crées a la compilation.

Euh non, du tout.
Même si ca en donne cette impression. Il y a bien une différence : tout ce qui est reflexion, tu obtient bien des propriétés et non des getter/setter, en prime tu as bien des informations sur la propriété (readonly, writeonly, attributs, etc...)
Et mine de rien on y accède souvent, même de manière implicite (sérialisation, affichage d'un objet dans une grille, binding, etc...)
Ca fait véritablement parti du MSIL, ca n'est pas un truc que le compilateur retire pour transformer ca en deux méthodes banales.

[cs_ntd]

Euh non, du tout.

Je suis désolé, mais regarde un code MSIL désassemblé, tu verra des getters et des setters apparaitre...
J'ai bien précisé que les Propriétés restaient présentes, mais en tant que référence vers ces getters/setters.

[ctxnop]

Je suis désolé, mais regarde un code MSIL désassemblé, tu verra des getters et des setters apparaitre...

Bien sur qu'ils apparaissent, pas dit le contraire...

J'ai bien précisé que les Propriétés restait présente, mais en tant que référence vers ces getters/setters.

Pas compris ca comme ca