Utilité du mot clé params

Version imprimable

Voir 40 message(s) de cette discussion en une page

Pour etre définitivement plus clair :

Code C# :

Code:

1
2
3
4
5
6
 
public ProgramWorkProduct RawRatios
{
            get { return rawRatios; }
            set { rawRatios = value; }
}

Codes MSIL :

Code:

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
 
//property
.property instance class Program.ProgramWorkProduct
        RawRatios()
{
  //appel au getter
  .get instance class Program.ProgramWorkProduct Program.frmMainProgram::get_RawRatios()
  //appel au setter
  .set instance void Program.frmMainProgram::set_RawRatios(class Program.ProgramWorkProduct)
} // end of property frmMainProgram::RawRatios
 
 
//setter
.method public hidebysig specialname instance void 
        set_RawRatios(class Program.ProgramWorkProduct 'value') cil managed
{
  // Code size       8 (0x8)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldarg.1
  IL_0002:  stfld      class Program.ProgramWorkProduct Program.frmMainProgram::rawRatios
  IL_0007:  ret
} // end of method frmMainProgram::set_RawRatios
 
 
//getter
.method public hidebysig specialname instance class Program.ProgramWorkProduct 
        get_RawRatios() cil managed
{
  // Code size       7 (0x7)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldfld      class Program.ProgramWorkProduct Program.frmMainProgram::rawRatios
  IL_0006:  ret
} // end of method frmMainProgram::get_RawRatios

Signature d'une méthode "normale" :

Code:

.method private hidebysig instance void tuneGUIStatus() cil managed

On voit donc bien qu'il y a 2 nouvelles fonctions qui apparaissent, meme si la propriétée ne disparait pas...

13/05/2011, 20h45
tomlev

Citation:

j'hésite toujours 10 minutes pour comprendre ce que fait x => x.Distance < 20.

C'est parce que tu ne l'as pas assez utilisé ;)
C'est vraiment une question d'habitude... au début j'avais aussi un peu de mal à lire les expressions lambda, mais à force de s'en servir ça devient complètement naturel

En ce qui concerne le débogage, on peut mettre des breakpoints dans les expressions lambda, et vérifier les valeurs.

C'est vrai qu'en général Linq ne facilite pas le débogage, mais comme ça permet généralement d'écrire un code beaucoup plus lisible, il y a moins de risques de faire des erreurs : le code exprime exactement ce qu'il fait, on voit beaucoup plus clairement la logique. Enfin c'est mon avis en tous cas...
13/05/2011, 21h47
ctxnop

oui je sais que c'est parce que je ne l'ai pas assez utilisé, mais j'ai beau le voir 15 fois par jour je ne m'y fais pas. Pour le débogage, j'ai dis qu'on ne pouvait pas inspecter les valeurs d'une expression LinQ (en cours d'exécution, genre a la 5ième itération) et que les expression lambda et LinQ empêchent la modification de la fonction (Edit&Continue).
Je n'ai pas prétendu qu'on ne pouvait pas mettre de point d'arrêt dans une expression lambda.

Dans l'ensemble, quand LinQ est utilisé pour faire une recherche d'objet dans une liste répondant à un critère pas trop complexe, je trouve aussi que ca simplifie la lecture (mis a part l'hésitation que j'ai sur quelques bouts de syntaxes), mais quand il commence a y avoir un peu trop de critère avec des méthodes d'extensions dans tous les sens, c'est plus du tout lisible.
Je crois qu'un des trucs qui me perturbe le plus dans LinQ c'est aussi l'ordre de la requête. Ca ressemble beaucoup a du SQL mais a l'envers, en SQL c'est SELECT <...> FROM <...> WHERE et en LinQ c'est FROM <...> WHERE <...> SELECT.
Au final c'est vraiment rien, mais quand même, j'arrive pas a m'y faire, je sais pas pourquoi.
13/05/2011, 23h21
tomlev

Citation:

Envoyé par ctxnop

j'ai dis qu'on ne pouvait pas inspecter les valeurs d'une expression LinQ (en cours d'exécution, genre a la 5ième itération)
[...]
Je n'ai pas prétendu qu'on ne pouvait pas mettre de point d'arrêt dans une expression lambda.

Je ne vois pas trop en quoi c'est différent :koi:
Tu mets le breakpoint dans ton expression, et tu peux changer les options du breakpoint pour qu'il ne s'arrête qu'au 5e passage si tu veux... ou alors j'ai pas compris ce que tu voulais dire

Bah dans l'exemple de DonQuiche :
Code:

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);
Comment tu met un point d'arrêt la dedans qui s'arrêtera a chaque itération afin d'inspecter les variables genre t.Interest, t.Langage, etc... ?
Pour autant que je sache tu ne peux pas.

Par contre les expression lambda genre
Code:

1 2 3 4 5 TestDelegate myDel = n => { string s = n + " " + "World"; Console.WriteLine(s); };
Tu peux mettre un point d'arrêt sur chacune des lignes de l'expression exactement comme s'il s'agissait d'une fonction "normale".

Tu parles d'options du breakpoint, je ne suis pas au courant de ca. Je sais mettre des conditions sur les breakpoints, mais j'ai pas fait le rapprochement avec une utilisation dans une expression LinQ. Si tu as une méthode pour parcourir l'exécution d'une expression LinQ en pas à pas, ca m'intéresse fortement.

14/05/2011, 03h52
tomlev

Citation:

Envoyé par ctxnop

Comment tu met un point d'arrêt la dedans qui s'arrêtera a chaque itération afin d'inspecter les variables genre t.Interest, t.Langage, etc... ?
Pour autant que je sache tu ne peux pas.

Si, bien sûr... tu places le curseur dans le corps de l'expression lambda et tu fais F9. Sous VS2010 en tous cas ça marche, pour VS2008 je sais plus...

Citation:

Envoyé par ctxnop

Tu parles d'options du breakpoint, je ne suis pas au courant de ca.

Bah y a plein d'options dans le menu contextuel du breakpoint : conditions, hit count, filter, etc...

Citation:

Envoyé par ctxnop

Si tu as une méthode pour parcourir l'exécution d'une expression LinQ en pas à pas, ca m'intéresse fortement.

Non, pas vraiment pas à pas... mais si tu mets un breakpoint sans condition sur l'expression lambda, tu t'arrêteras à chaque itération, ce qui revient un peu au même
14/05/2011, 13h02
ctxnop

Citation:

Envoyé par tomlev

Si, bien sûr... tu places le curseur dans le corps de l'expression lambda et tu fais F9. Sous VS2010 en tous cas ça marche, pour VS2008 je sais plus...

Etrange, a chaque fois que j'ai tenté sur un VS2010 ca n'a pas marché, il s'arrêtait bien une fois sur le breakpoint, mais même en faisant un pas a pas rentrant il sautait directement a l'instruction d'après. Comme ca a fait pareil chez mes collègues je ne me suis pas poser la question d'un possible bug, si on peut effectivement faire en sorte que ca marche je vais peut etre réviser mon appréciation des expressions LinQ.
Merci de l'info en tout cas, car du coup maintenant je vais chercher pourquoi ca fonctionne pas chez nous.
14/05/2011, 13h27
Nathanael Marchand

Atttention on parle du linq avec les méthodes d'extensions .Where() .Join() etc et pas de celui qui ressemble à du SQL.
14/05/2011, 13h52
tomlev

Citation:

Envoyé par ctxnop

Etrange, a chaque fois que j'ai tenté sur un VS2010 ca n'a pas marché, il s'arrêtait bien une fois sur le breakpoint, mais même en faisant un pas a pas rentrant il sautait directement a l'instruction d'après.

Bah c'est normal, c'est déroulement réel du programme... quand tu énumères le résultat d'une requête Linq, la source des données est "streamée" (désolé je trouve pas de bonne traduction en français), c'est à dire que la source est lue au fur et à mesure que tu lis les résultats. Donc par exemple une requête avec un Where, si tu l'énumères dans un foreach, ça va passer dans la condition du Where à chaque itération du foreach, mais pas avant que tu commences à boucler. Si tu t'attendais à ce que ça exécute la condition pour chaque item avant de rentrer dans la boucle, forcément ça surprend un peu...
14/05/2011, 15h02
Nathanael Marchand

Citation:

Envoyé par tomlev

Bah c'est normal, c'est déroulement réel du programme... quand tu énumères le résultat d'une requête Linq, la source des données est "streamée" (désolé je trouve pas de bonne traduction en français), c'est à dire que la source est lue au fur et à mesure que tu lis les résultats. Donc par exemple une requête avec un Where, si tu l'énumères dans un foreach, ça va passer dans la condition du Where à chaque itération du foreach, mais pas avant que tu commences à boucler. Si tu t'attendais à ce que ça exécute la condition pour chaque item avant de rentrer dans la boucle, forcément ça surprend un peu...

Effectivement, pour la plupart le resultat est "yieldé" (instruction yield). Il n'y a que pour les opérations qui ont besoin de toute la collection que tout est parcouru (All, Sort, GroupBy,etc)
14/05/2011, 16h40
Bluedeep

Citation:

Envoyé par cs_ntd

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.

Des getters/setters ne sont pas détéctés par les serializer .(sauf binaire)

Ergo, ce n'est pas un sucre syntaxique.

A moins que la serialisation soit aussi un sucre syntaxique ....
Mais au final, c'est l'approche objet qui est un sucre syntaxique.

Voir 40 message(s) de cette discussion en une page