Discussion :

[ijk-ref]

Bonjour

Je ne comprends pas l'intérêt du mot clé "dynamic" ! Quelqu'un peut me l'expliquer ?

Car les exemples qu'ils en donnent sont pour interfacer Office en COM pour ainsi lancer n'importe quelles méthodes sans aucunes vérifications à la compilation !

Ne serait-il pas mille fois plus logique qu'Office fournissent une interface .NET qui sera par définition ultra-typée et permettra de ne pas écrire n'importe quoi et vérifié à la compilation ?

.NET a déjà plus de 10 ans... comment ça se fait qu'office ne puisse pas avoir une interface .NET qui me semblait pourtant le but initial de microsoft !?

[calagan99]

Bonjour

Je ne comprends pas l'intérêt du mot clé "dynamic" ! Quelqu'un peut me l'expliquer ?

Car les exemples qu'ils en donnent sont pour interfacer Office en COM pour ainsi lancer n'importe quelles méthodes sans aucunes vérifications à la compilation !

Ne serait-il pas mille fois plus logique qu'Office fournissent une interface .NET qui sera par définition ultra-typée et permettra de ne pas écrire n'importe quoi et vérifié à la compilation ?

Pourquoi est-il absurde?
Il n'est pas utile tous les jours, mais je ne vois pas en quoi il est absurde.
Qui plus est, tu dis toi même ne pas en comprendre le fonctionnement...
Effectivement, le fait que le code ne soit vérifié qu'à l'exécution est potentiellement dangereux. Cela dit, "dynamic" simplifie quand même considérablement la manipulation d'objets COM par exemple.

Dans le cas d'office, le type dynamic simplifie quand même pas mal la manipulation d'Office... Fini les cast dans tous les sens notamment...

[ijk-ref]

Pourquoi est-il absurde?
Il n'est pas utile tous les jours, mais je ne vois pas en quoi il est absurde.
Qui plus est, tu dis toi même ne pas en comprendre le fonctionnement...

Je n'ai jamais dit que je ne comprenais pas son fonctionnement !

Effectivement, le fait que le code ne soit vérifié qu'à l'exécution est potentiellement dangereux. Cela dit, "dynamic" simplifie quand même considérablement la manipulation d'objets COM par exemple.

Dans le cas d'office, le type dynamic simplifie quand même pas mal la manipulation d'Office... Fini les cast dans tous les sens notamment...

J"en connais parfaitement l'intérêt syntaxique et je suis parfaitement d'accord qu'il simplifie grandement l'écrit de la Réflexion. C''est d'ailleurs très bien dans ce cas.

Par contre NON je ne comprends son utilité pour communiquer avec Office !

Est ce que qu'il existe encore des personnes cherchant à communiquer entre c# 4.0 et Office 1.0 !?

Bien sûr que non !

La vraie question est pourquoi ne peut-on pas interfacer Office directement en .Net avec un typage fort rendant mot clé "dynamic" complètement inutile dans ce cas là !?

Ce serait mille fois plus logique et dans la philosophie de C# qui est justement le typage fort et la prévention des erreurs à la compilation.

[calagan99]

Certes ce serait plus simple.
Mais en attendant, cet ajout dans le FW 4.0 est quand même loin d'être absurde... Il simplifie énormément l'automation d'Office, c'est déjà un pas énorme...

[ijk-ref]

Certes ce serait plus simple.
Mais en attendant, cet ajout dans le FW 4.0 est quand même loin d'être absurde... Il simplifie énormément l'automation d'Office, c'est déjà un pas énorme...

Non ! Rajouter une couche de programmation dynamique dans un langage fortement typé est une parfaite régression !

Je suis sûr que si un utilisateur lambda s'était plaint du manque du typage dynamique en C#... n'importe quels responsables de c# lui auraient rit au nez (avant la version 3)

Fournir une interface typée me semble bien plus simple et efficace à fournir... surtout que COM est plus que vieux et .NET à plus de 10 ans.

Non je ne comprends pas cette direction !

[binoo]

Salut,

En quoi ajouter un mot clé (une fonctionnalité) est une régression. Son utilisation n'est pas une obligation.

Car les exemples qu'ils en donnent sont pour interfacer Office en COM pour ainsi lancer n'importe quelles méthodes sans aucunes vérifications à la compilation !

Ne serait-il pas mille fois plus logique qu'Office fournissent une interface .NET qui sera par définition ultra-typée et permettra de ne pas écrire n'importe quoi et vérifié à la compilation ?

Un exemple n'a pas pour but premier d'être logique. Il est avant tout là pour montrer comment l'utiliser. Donc l'utilisation d'office dans leur exemple n'est pas forcément sujet à débat... Le mot clé dynamic est applicable pour tout type d'objet COM.

Après pourquoi n'y a-t-il pas une interface .NET pour manipuler Office... ça il faudrait être dans les petits papiers de Microsoft pour comprendre...

[tomlev]

Rajouter une couche de programmation dynamique dans un langage fortement typé est une parfaite régression !

Pas nécessairement, le typage statique fort et le typage dynamique ont tous les deux leur utilité... Dans la plupart des cas, il est préférable d'utiliser le typage statique, mais il y a des scénarios où le typage dynamique a ses avantages. Par exemple, entre utiliser un dictionnaire où tu spécifies la clé comme une chaine de caractères (donc non vérifié par le compilateur), et utiliser un ExpandoObject qui fait la même chose avec une syntaxe plus pratique, le choix est vite fait.

Pour ce qui est d'Office, c'est vrai que ce serait mieux d'avoir une vraie interface .NET, mais Office n'étant pas développé en .NET à ma connaissance, COM est une solution de repli viable... D'ailleurs il n'y a pas qu'Office, l'interop COM peut servir à plein d'autres choses, dont on ne peut pas attendre qu'elles aient une interface en .NET

[ijk-ref]

En quoi ajouter un mot clé (une fonctionnalité) est une régression. Son utilisation n'est pas une obligation.

T'inquiètes, cette fonctionnalité me manquait aussi lorsque je faisais de la réflexion

Cependant après une réflexion (trop) rapide j'aurai préféré un truc du genre Type<T> où peut être dynamic<T> permettant d'éviter de pouvoir écrire n'importe quoi.

Pas nécessairement, le typage statique fort et le typage dynamique ont tous les deux leur utilité... Dans la plupart des cas, il est préférable d'utiliser le typage statique, mais il y a des scénarios où le typage dynamique a ses avantages. Par exemple, entre utiliser un dictionnaire où tu spécifies la clé comme une chaine de caractères (donc non vérifié par le compilateur), et utiliser un ExpandoObject qui fait la même chose avec une syntaxe plus pratique, le choix est vite fait.

Je ne remets pas en cause son utilité dans l'accès au DOM tel que XML apportant une grande simplification.

Cependant si les choses sont bien faites... normalement tout devrait être encapsulé dans des classes permettant la même choses tout en ayant une vérification plus forte à la compilation

Pour ce qui est d'Office, c'est vrai que ce serait mieux d'avoir une vraie interface .NET, mais Office n'étant pas développé en .NET à ma connaissance, COM est une solution de repli viable... D'ailleurs il n'y a pas qu'Office, l'interop COM peut servir à plein d'autres choses, dont on ne peut pas attendre qu'elles aient une interface en .NET

Office n'est pas plus programmé en .COM L'interface est indépendant du développement.

Et puis un vraie question : à part Office, DirectX ou encore d'autres produits Microsoft... vous connaissez des utilisations courantes d'interfaces COM ?

Quels boites sont tellement à jour qu'elles programment en c# 4 tout en ayant besoin d'interfaces archaïques COM !?

J'ai encore le souvenir de mon 1er bouquin C# 1 ventant les mérites des bibliothèques .NET pour éviter l'enfer des dll classiques et les interfaces COM poussifs !

[tomlev]

C'est sûr que COM est dépassé depuis belle lurette, bien qu'il n'ait malheureusement pas encore disparu... Mais l'interop COM n'est qu'un usage parmi d'autres de dynamic, ça peut servir par exemple à s'interfacer avec des langages dynamiques (par exemple IronPython, IronRuby...), ou d'une manière générale avec n'importe quel modèle objet qui n'a pas d'interface fortement typée

[Nathanael Marchand]

Et puis un vraie question : à part Office, DirectX ou encore d'autres produits Microsoft... vous connaissez des utilisations courantes d'interfaces COM ?

Quels boites sont tellement à jour qu'elles programment en c# 4 tout en ayant besoin d'interfaces archaïques COM !?

Mon équipe (celle ou je travaille)! Dans une des plus grosses banques d'investissement mondiale, l'appli a 15ans il est hors de question de refondre certaines librairies métiers en C++ et on fait pourtant du .Net 4 et Silverlight pour le GUI! On utilise également un système de script en VB et JScript pour le reporting -> on expose nos assembly en COM. Bref, même si je suis le premier à râler contre COM, à vouloir décomissioner le C++ le fait est que COM est la et il nous rend de bons services (quand ca marche )

[ijk-ref]

C'est sûr que COM est dépassé depuis belle lurette, bien qu'il n'ait malheureusement pas encore disparu... Mais l'interop COM n'est qu'un usage parmi d'autres de dynamic, ça peut servir par exemple à s'interfacer avec des langages dynamiques (par exemple IronPython, IronRuby...), ou d'une manière générale avec n'importe quel modèle objet qui n'a pas d'interface fortement typée

OK pour ces cas là. Cependant j'émets un doute quand tu dis que l'interop COM n'est qu'un usage parmi d'autre... car c'est toujours celui montré en exemple

Mon équipe (celle ou je travaille)! Dans une des plus grosses banques d'investissement mondiale, l'appli a 15ans il est hors de question de refondre certaines librairies métiers en C++ et on fait pourtant du .Net 4 et Silverlight pour le GUI! On utilise également un système de script en VB et JScript pour le reporting -> on expose nos assembly en COM. Bref, même si je suis le premier à râler contre COM, à vouloir décomissioner le C++ le fait est que COM est la et il nous rend de bons services (quand ca marche )

Et vous utiliser donc directement "dynamic" ? Vous n'avez pas plutôt créé une interface .NET à partir de celle en COM ?

Tu connais C++/CLI ? Un wrapper entre COM et .NET est facile pourtant... enfin je crois

[Nathanael Marchand]

OK pour ces cas là. Cependant j'émets un doute quand tu dis que l'interop COM n'est qu'un usage parmi d'autre... car c'est toujours celui montré en exemple

Et vous utiliser donc directement "dynamic" ? Vous n'avez pas plutôt créé une interface .NET à partir de celle en COM ?

Tu connais C++/CLI ? Un wrapper entre COM et .NET est facile pourtant... enfin je crois

Le seul moment ou j'utilise dynamic c'est en Silverlight pour une bidouille qui génère des tableaux croisés dynamiques dans la datagrid Silverlight. Je le fais en Javascript style (création d'un type par reflexion et utilisation de celui ci)
Mais effectivement, je connais C++/CLI sauf que y'a pas assez de sous pour migrer

[DonQuiche]

Le mot clé a rarement son utilité, nous sommes tous d'accord. Mais quand c'est utile, c'est aussi souvent indispensable, alors je n'irai pas faire la fine bouche. Et il faut bien garder à l'esprit qu'il a avant tout été ajouté pour l’interopérabilité avec des langages à typage faible, pas pour COM.

[ijk-ref]

Le mot clé a rarement son utilité, nous sommes tous d'accord. Mais quand c'est utile, c'est aussi souvent indispensable, alors je n'irai pas faire la fine bouche. Et il faut bien garder à l'esprit qu'il a avant tout été ajouté pour l’interopérabilité avec des langages à typage faible, pas pour COM.

Si c'est vraiment pour ça OK !

J'espère seulement ne pas retrouver du code classique c# déclaré uniquement avec du "dynamic"

[istace.emmanuel]

Pour ma part j'essaye de l'utiliser que quand cela est absolument nécessaire (scénario d'interop com et cie)

Le code C# faiblement typé commence a apparaitre de plus en plus dans des cas ou ce n'est pas nécessaire et ça me fait légèrement vomir.

Le typage fort était pour moi un des atouts majeurs de dotnet.

Mais bon, du code full dynamic je ne pense pas que ça apparaitra car dynamic == no intellisense... Et c'est génial l'intellisense

Pour office, entièrement d'accord avec toi, vivement un interface dotnet propre d'office.

[ijk-ref]

Le code C# faiblement typé commence a apparaitre de plus en plus dans des cas ou ce n'est pas nécessaire et ça me fait légèrement vomir.

Oui ça fait peur !

[olivieram]

Moi, je trouve que dynamic est une petite évolution mais aussi une application de C++.

Parce que s'il l'on y réflechit bien et si l'on observe l'évolution des langages de programmation en partant du C, C++, Java puis C#, en passant par le scripting, eh bien on constate que C# fait évoluer la notion de typage en sachant implémenter dans son compilateur et son langage favori un typage fort et un typage non fort.
Alors qu'en C, l'on avait (void*) dans ce langage pour exprimer quelque chose dans un buffer, avec dynamic de C#, on a en plus la notion dynamique (c'est le cas de le dire) de l'objet, de son contenu et de ses méthodes.
Je conclus donc que dynamic est une application de C++ (quand on pointe en fait sur un objet) qui est une évolution de C avec (void*).
Le fait que l'on ait COM n'est pas anodin (c'est du C++ initialement).
Je ne sais pas si vous avez tout compris ce que j'ai dis ?

[DonQuiche]

Sauf que l'équivalent de "void*", c'est "object", ce concept de type racine n'existant d'ailleurs pas en C++ (aucun besoin)...

Qui plus est typage faible et typage dynamique sont deux choses différentes : une des propriétés rencontrées dans les langage à typage faible est que les membres et méthodes ne sont pas, ou pas seulement, définis au niveau du type lui-même mais par instance : en javascript par exemple, on peut ajouter des méthodes à un objet à la volée, comme avec ExpandoObject en C# désormais. C'est pour interagir avec ce type d'objets que "dynamic" a été introduit et il n'y a absolument aucun équivalent en C++ (impossible d'interroger un membre d'une variable de type "void*").

[ijk-ref]

Cool ! J'adore ces sujets de "bistrot" ! Je n'étais pas sur que la sauce prenne... mais si on dirait que si !


J'en lancerai bien un autre pour le mot "var"

S'il est très bien, je trouve dommage qu'ils ne soient pas allé au bout avec les classes anonymes.

L'idéal aurait été AUSSI de pouvoir en non-nommer n'importe où.

par exemple comme ça :

Code :

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

(double Key, string Value) Elements(int index);

Ainsi les classes KeyValuePair et autres Tuples deviendraient inutiles.


Car franchement la classe Tuple ressemble à du bricolage/bidouillage avec ses multiples déclarations !

Note : non je ne veux pas de réponses du genre "si t'as des idiées va les proposer à 'crosoft"

[tomlev]

J'en lancerai bien un notre pour le mot "var"

Je suppose que tu voulais dire "un autre"
Ouvre une nouvelle discussion alors, sinon on sait plus de quoi on parle...

Note : non je ne veux pas de réponses du genre "si t'as des idiées va les proposer à 'crosoft"

Ca a déjà été proposé par plein de gens... mais je pense pas qu'il faut attendre ça pour C# 5. Le focus de la v5 est plutôt sur "async" et "Compiler As A Service"