Discussion :

[tomlev]

Pour l'instant, j'ai l'impression que Microsoft a réussi à faire utiliser toutes les features qu'ils ont ajoutées (même si je n'ai pas encore beaucoup vu d'usages de in/out pour la co-Contravariance, ou de dynamic pour le dispatch dynamique)

La covariance ça sert pas mal en fait, souvent sans même y penser : ça parait assez naturel qu'une List<Giraffe> puisse être considérée comme un IEnumerable<Animal> (il faut réfléchir un peu plus pour comprendre pourquoi ce n'est pas une IList<Animal> mais bon...). La contravariance c'est un peu plus rare, mais ça arrive quand même de s'en servir. Par exemple, si tu as un IEqualityComparer<Animal>, ça semble logique qu'il puisse servir de IEqualityComparer<Giraffe> (s'il peut comparer des animaux, il peut comparer des girafes). Bon après, c'est sûr qu'on définit pas des interface ou délégués co- ou contravariants tous les jours...

dynamic, pour le coup, je ne m'en sers absolument pas. C'est utile pour des scénarios assez spécifiques, comme l'interop avec Office ou avec des langages dynamiques, mais en dehors de ça je ne vois pas vraiment l'intérêt.

Mais dans l'ensemble c'est vrai que la plupart des features ajoutées à C# ont une vraie utilité, et sont d'habitude assez largement adoptées. Même des features "gadgets" comme les paramètres optionnels ont leur utilité et permettent de "fluidifier" l'écriture et la lecture du code.

[Guulh]

La covariance ça sert pas mal en fait, souvent sans même y penser

Utiliser bien sûr, je veux dire qu'hormis ce que le framework propose, e je n'ai pas vu de classe générique qui spécifie Bidule<out T> explicitement.

dynamic, pour le coup, je ne m'en sers absolument pas.

Ben je voyais récemment que ça peut se permettre de se passer de Double Dispatch. On préfère chez nous en rester à notre bon vieux visitor pour gérer ça.

[Nathanael Marchand]

Utiliser bien sûr, je veux dire qu'hormis ce que le framework propose, e je n'ai pas vu de classe générique qui spécifie Bidule<out T> explicitement.

Oui car c'est réservé aux interfaces et délégués Mais personnellement, je le mets toujours quand c'est possible (Resharper m'aide bien à le déterminer d'ailleurs)

Ben je voyais récemment que ça peut se permettre de se passer de Double Dispatch. On préfère chez nous en rester à notre bon vieux visitor pour gérer ça.

Ca c'est super cool comme truc et je trouve que c'est une bonne utilisation
Le problème du dynamique c'est que c'est un mot clef assez "épidémique": dès qu'on l'utilise il se propage partout (via les signatures). Donc, une utilisation contenue comme ca est pas mal.

[jmnicolas]

VSnet 2012, lorsqu'on est une entreprise (hors autoentrepreneur), ca coute environ 500 euros HT (version pro), c'est presque donné (regardé le coût des plugins Xamarin pour comparaison ...)

Je suis d'accord avec toi, surtout qu'on dépense des millions ailleurs.

J'aurais beaucoup à dire à propos des décisions budgétaires de ma boite, mais comme je poste sous mon vrai nom, je vais essayer de garder mon job

[tomlev]

Ben je voyais récemment que ça peut se permettre de se passer de Double Dispatch. On préfère chez nous en rester à notre bon vieux visitor pour gérer ça.

Intéressant... C'est un peu du bricolage, mais je vois un cas où ça m'aurait bien servi pour une appli au boulot. Je garde ça sous le coude en tous cas

[Orwel]

Il manque dans le sondage, "Je ne travaille pas avec un framework compatible".

Je suis encore .net 4 sous VS2010 au travaille, mais j'attends avec plus d'impatience la prochaine update de nos services.

Malheureusement, je n'ai pas ce genre de besoin pour mes projets personnels.

[manuel_o]

Bonjour à tous,
L'exemple donné à le mérite d'être très simple mais l'avantage réel d'utiliser async/await est surtout remarquable dans des configurations de code un peu plus complexes.
Par exemple on peut utiliser await dans des blocs try/catch alors que si on développe le code sans ces mots clés on obtient des constructions beaucoup plus complexes et beaucoup moins lisibles.

[tomlev]

Par exemple on peut utiliser await dans des blocs try/catch alors que si on développe le code sans ces mots clés on obtient des constructions beaucoup plus complexes et beaucoup moins lisibles.

C'est vrai, je me souviens avoir pas mal galéré avec les ContinueWith en .NET 4, où il fallait vérifier le statut de la tâche pour savoir si elle avait réussi, c'était vraiment pas pratique... Par contre, petite précision : on peut utiliser await dans les blocs try, mais pas dans les blocs catch... Ce qui fait qu'on ne peut pas écrire quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
    try
    {
        await DoSomethingAsync();
    }
    catch(Exception ex)
    {
        var dlg = new MessageDialog(ex.ToString(), "Error");
        await dlg.ShowAsync();
    }

On est obligé de faire une pirouette :

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
 
    string errorMessage = null;
    try
    {
        await DoSomethingAsync();
    }
    catch(Exception ex)
    {
        errorMessage = ex.ToString();
    }
 
    if (errorMessage != null)
    {
        var dlg = new MessageDialog(errorMessage, "Error");
        await dlg.ShowAsync();
    }

Ce qui est déjà nettement moins clair... mais bon, c'est quand même mieux qu'avec des Task

[Nathanael Marchand]

C'est vrai, je me souviens avoir pas mal galéré avec les ContinueWith en .NET 4, où il fallait vérifier le statut de la tâche pour savoir si elle avait réussi, c'était vraiment pas pratique... Par contre, petite précision : on peut utiliser await dans les blocs try, mais pas dans les blocs catch... Ce qui fait qu'on ne peut pas écrire quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
    try
    {
        await DoSomethingAsync();
    }
    catch(Exception ex)
    {
        var dlg = new MessageDialog(ex.ToString(), "Error");
        await dlg.ShowAsync();
    }

On est obligé de faire une pirouette :

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
 
    string errorMessage = null;
    try
    {
        await DoSomethingAsync();
    }
    catch(Exception ex)
    {
        errorMessage = ex.ToString();
    }
 
    if (errorMessage != null)
    {
        var dlg = new MessageDialog(ex.ToString(), "Error");
        await dlg.ShowAsync();
    }

Ce qui est déjà nettement moins clair... mais bon, c'est quand même mieux qu'avec des Task

Tu connais ca sinon ?

Code :

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

1
2
3
4
5
 
var t = DoSomethingAsync();
var tHandle = t.ContinueWith(HandleErrror, TaskContinuationOptions.OnlyOnFaulted); //équivaut au catch
var tNext = t.ContinueWith(HandleNext, TaskContinuationsOptions.NotOnFaulted);
Task.Factory.ContinueWhenAny(WhatsNext, new []{tHandle, tNext});

(c'est de tête hein)
Bon j'avoue que c'est pas forcément plus lisible mais il y'a bien des cas ou je préfère mais c'est plus souvent quand je fais du parallélisme que de l'asynchronisme

[tomlev]

Tu connais ca sinon ?

Oui mais j'aime pas trop... Je trouve pas ça lisible, et je me souviens jamais ce qui se passe si je fais par exemple "NotOnFaulted" et qu'il y a une erreur...

Par contre, il y a un truc qui peut arranger un peu les choses, c'est la méthode Then proposée par Stephen Toub :
http://blogs.msdn.com/b/pfxteam/arch.../10094564.aspx

[sinople]

Je l'utilise pas encore, principalement parce que je développe pour Winforms sur des postes XP avec VS2010 et que même si on peut bricoler pour en bénéficier je ne m'amuse pas à le faire vu qu'il s'agit plus d'une "simplification de syntaxe" que d'une nouvelle key feature.

Charger des données sans bloquer l'interface étant quand même une problématique pas très nouvelle, pour laquelle on s'est déjà fait proposer des solutions "simple" par Microsoft (comme le background worker). Je vois pas l'intérêt de faire la girouette et de me retrouver avec plusieurs façons de faire pour résoudre le même problème (en plus cette dernière ne permet pas d'afficher une progression, en l'état).

Il faut aussi être conscient que cette fonctionnalité a été livrée avec un package un peu plus conséquent concernant le chargement des données dans un contrôle d'affichage asynchrone. (sujet sur lequel je vais pas m'étendre car depuis la présentation je n'ai pas approfondi le sujet)

Bien entendu, le jour ou on décidera de laisser tomber Winforms pour Modern UI ou le prochain truc qui suivra, bien entendu que je réviserais mon jugement sur l'utilisation de cette fonctionnalité!

[tomlev]

vu qu'il s'agit plus d'une "simplification de syntaxe" que d'une nouvelle key feature.

Si tu penses que c'est juste une simplification de syntaxe, c'est clairement que tu ne l'as pas utilisé... tu changeras certainement d'avis le jour où tu t'en serviras

(en plus cette dernière ne permet pas d'afficher une progression, en l'état).

Bah si, regarde mon exemple un peu plus haut... ça permet même de le faire plus simplement qu'avant.

Il faut aussi être conscient que cette fonctionnalité a été livrée avec un package un peu plus conséquent concernant le chargement des données dans un contrôle d'affichage asynchrone. (sujet sur lequel je vais pas m'étendre car depuis la présentation je n'ai pas approfondi le sujet)

C'est à dire ? Je ne vois pas de quoi tu parles

[I_Pnose]

Je fais partie de ceux qui sont tombé sous le charme ; ça m’évite de me tordre les neurones avec les delegate et leur BeginInvoke/EndInvoke (ou de passer par des threads par pure flemme).
Bref, du tout bon.

[BenoitM]

Utiliser bien sûr, je veux dire qu'hormis ce que le framework propose, e je n'ai pas vu de classe générique qui spécifie Bidule<out T> explicitement.

Bête question à quoi sert le out?

[tomlev]

Bête question à quoi sert le out?

A indiquer que le type Bidule est covariant en T (in indique que c'est contravariant)

L'exemple classique est IEnumerable<out T> ; la contravariance permet de faire ça :

Code :

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

1
2
IEnumerable<Giraffe> giraffes = new List<Giraffe>();
IEnumerable<Animal> animals = giraffes;

Avant C# 4, tu aurais eu une erreur de compilation, même si ça semblait évident qu'une séquence de girafes était aussi une séquence d'animaux...

Mais attention, le principe ne peut pas s'utiliser de façon aussi générale qu'on pourrait le croire... par exemple l'interface IList<T> n'est pas covariante ; si elle l'était, ça permettrait d'écrire ça :

Code :

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

1
2
3
IList<Giraffe> giraffes = new List<Giraffe>();
IList<Animal> animals = giraffes;
animals.Add(new Dog());

animals est toujours une instance de List<Giraffe>, donc ajouter un chien à cette liste échouerait à l'exécution. Mais comme l'interface n'est pas covariante, le compilateur ne te laisse pas faire ce genre d'erreur.

cf. cet article: Variance en C# 4

[BenoitM]

merci

J'avais lu qu'il avait introduit le covariant et le contravariant mais je me souvenait plus qu'il fallait out/in pour que celle-ci marche.

[Cyrilange]

J'utilise encore le bon vieux BackgroundWorker (Framework 4 et WPF) qui est simple et efficace pour toutes sortes de tâches. Je peux même appeler des méthodes synchrones depuis un BackgroundWorker en utilisant un delegate et les rendre asynchrone.
J'essayerais une autre méthode quand celle-ci ne me donnera plus entière satisfaction.

[DonQuiche]

Utilisez-vous le nouveau modèle de programmation asynchrone ? En C# ou en VB.NET ? Sur quelle plateforme (bureau, Windows Phone, WinRT, ASP.NET…) ?

Je l'ai utilisé en C# à l'occasion d'un programme Windows Store et je le réutiliserai certaines fois.

Il me semble très bien adapté pour les tâches à réaliser en arrière-plan de l'UI (ou tout autre système avec des objets ayant une affinité avec certains threads) et pour les data flows avec de longues périodes d'attente (vivent les continuations).

Puisque ces cas sont les plus fréquents, async/await constituent une excellente addition à C#. Mais sorti de ces cas de figure l'outil devient vite limité à mon goût et il y bien des problèmes de concurrence pour lesquels je préfère me passer entièrement d'async/await pour un contrôle plus direct.