Discussion :

[Jérôme Lambert]

Une fois de plus, c'est lors de la Microsoft PDC que nous apprenons cette grande nouvelle : Les langages du .NET Framework, et plus particulièrement C# et Visual Basic, évolueront conjointement. Rassurez-vous, cette coévolution ne concerne que les fonctionnalités, ce qui signifie que lorsque l'équipe Visual Basic mettra en place une nouvelle fonctionnalité pour son langage, cette fonctionnalité sera implémentée par l'équipe C# aussi, et vice-versa.

Ceci sera d'application pour C# 4.0 et VB.NET 10 et pour ceux qui veulent voir l'annonce faîtes par les responsables des équipes C# et VB.NET, je vous invite à aller voir les webcasts suivantes :

• The Future of C# présenté par Anders Hejlsberg

• Future Directions for Visual Basic présenté par Paul Vick et Lucian Wischik

Votre avis sur cette nouvelle ?

[Billet source]

[DroP]

C'est une très bonne initiative ! cela va permettre d'être plus cohérent lorsque l'on passe de l'un à l'autre, et justement de pouvoir réaliser la même chose de la même manière que ce soit en c# ou en VB.Net

[Philippe Vialatte]

Il etait temps

Ceci dit, j'entends deja les C#-eurs purs et durs raler parce que maintenant, ils auront des paramètres optionnels

Comme ca c'est parfait, d'ici deux ans, on n'aura plus a préparer 2 jeux de slides par formation, tout le monde aura les mêmes fonctionnalités, yes !

[callo]

Très cool. Le choix du langage .Net à utiliser ne sera dès lors plus une question de supériorité d'un langage sur l'autre mais plutôt une question de goût.

[Kikos31]

Personnelement j'approuve mais je pense que ça va sérieusement grincer des dents chez certains 'C# lovers'.

Les nouveautés du C# 4 le rapproche beaucoup de VB.NET.

Les paramètres optionnels et nommés était souvent critiqués mais c'est le mot clé 'dynamic' qui mettre le feu au poudre :

Du bon vieux late binding à la VB !! (mais en mieux car la granularité est bien meilleure : espéront qu'il en sera de même sur VB).

Sinon, l'évaluation de code dynamique est quelque chose que j'attendais (pour le moment c'est possible en référençant IronPyhton toutefois).

Par contre je n'ai pas vu d'indication que celà serait pour VB10 également.

Si quelqu'un peut confirmer ...

[smyley]

Les paramètres optionnels et nommés était souvent critiqués

En même temps ça fait longtemps que je l'attendais. Marre de faire 10 overloads qui ne font que qu'appeler la méthode suivante avec juste un paramètre en plus.

mais c'est le mot clé 'dynamic' qui mettre le feu au poudre

Là je suis d'accord, les premières impression que j'en ai eu ressemblent pas à quelque chose de 'bien'. ça a plus l'air calamiteux, mais peut être qu'il faut laisser le temps de voir ce que ça donne en pratique.

Je sais pas si c'est forcément bien que chaque fonctionnalité soit appliquée sur l'autre langage. C'est deux styles différents et ça va peut être aboutir à n'importe quoi de vouloir les rapprocher. (en même temps ça va faire qu'il n'y aura plus d'arguments pour continuer d'utiliser VB ... c'est un C# lover qui parle )

[Philippe Vialatte]

en même temps ça va faire qu'il n'y aura plus d'arguments pour continuer d'utiliser VB ... c'est un C# lover qui parle )

Malheureusement, la seule vraie raison de VB va rester...parce que le jour ou on pourra faire un option strict off en C#, j'aurais plus a faire des wrappers en VB pour generer mes documents word en C#


(ok, je sors....le jour ou on peut faire option strict off en C#, je retourne a Java )

[smyley]

Le VB est plus permissif que le C#, mais il me parait mieux d'avoir à se battre pour que ça compile pour qu'ensuite le programme fonctionne, plutôt que de devoir compiler tout facilement et qu'ensuite le programme crash de manière inattendue (remarque, pour les miens c'est le cas, mais c'est une autre histoire )

En même temps pourquoi faire des wrappers en VB ? qu'est-ce qui est franchement infaisable et qui justifie cette démarche ?

[Philippe Vialatte]

En même temps pourquoi faire des wrappers en VB ? qu'est-ce qui est franchement infaisable et qui justifie cette démarche ?

pas infaisable....juste tres tres ch...

allez, juste pour le fun...

creer un fichier word avec l'automation office...et le sauver

C#:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Object oMissing = System.Reflection.Missing.Value();
 
Word.Application oWord = new Word.Application();
Word.Document oWordDoc = new Word.Document();
 
oWordDoc = oWord.Documents.Add(ref oMissing, ref oMissing, ref oMissing, ref oMissing);
 
Object oSaveAsFile = (Object)"C:\\SampleDoc.doc";
oWordDoc.SaveAs(ref oSaveAsFile, ref oMissing, ref oMissing, ref oMissing,
    ref oMissing, ref oMissing,ref oMissing, ref oMissing, ref oMissing,
    ref oMissing, ref oMissing, ref oMissing, ref oMissing, ref oMissing,
    ref oMissing, ref oMissing);

VB.Net:

Code :

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

1
2
3
4
5
6
7
8
 
Dim oWord As new Word.Application();
Dim oWordDoc As new Word.Document();
 
oWordDoc = oWord.Documents.Add();
 
Dim oSaveAsFile as string = "C:\SampleDoc.doc";
oWordDoc.SaveAs(oSaveAsFile);

Le VB est quand meme plus lisible

[smyley]

Donc en gros tout ce qu'il manque c'est le support des paramètres optionnels pour mettre par défaut System.Reflection.Missing.Value() ...

[Kikos31]

Je sais pas si c'est forcément bien que chaque fonctionnalité soit appliquée sur l'autre langage. C'est deux styles différents et ça va peut être aboutir à n'importe quoi de vouloir les rapprocher. (en même temps ça va faire qu'il n'y aura plus d'arguments pour continuer d'utiliser VB ... c'est un C# lover qui parle )

C'est pas faux. Autant je trouve important qu'il soit possible de faire la même chose avec les 2 langages, autant il n'est peut être pas judicieux de le faire de la même manière.

Il y a déjà trés peu de différences entre un VB (avec les options strict/explicit off) et du C#. En les rapprochant encore plus, la nécessité d'avoir 2 langages ne sera pas évidente ... et ça pourrait amener à la mort d'un des 2.

Il ne reste plus qu'a virer ces anachronistes point virgules au C# , et l'appeler visual basic C#.

Et c'est un DotNet lover qui parle (peu importe le flacon pourvu...)

[davcha]

On a jamais dit que c# et vb allaient "fusionner" ou même que les fonctionnalités de l'un seraient copiées/collées dans l'autre.

Si vous réécoutez bien la conférence, il dit a un moment qu'à chaque fois qu'une des équipes se chargeant d'un des deux langages implémenterait une nouvelle fonctionnalité dans le langage en question, l'autre équipe travaillerait dur pour implémenter une fonctionnalité similaire dans l'autre langage.

Il ajoute, et c'est important, que les implémentations ne seraient pas forcément identiques, ni même forcément semblables, car ce qui est bon pour un langage ne l'est pas forcément pour l'autre.

(Je brode un peu : en fait, il se contente de dire que "la manière d'apporter la fonctionnalité pourrait être différente car plus adaptée", mais c'est ainsi que j'interprète ce qu'il dit).