C# 4 et dynamic
11 views
Skip to first unread message
DUVAL Olivier
Aug 7, 2009, 7:58:52 AM8/7/09
to paris...@googlegroups.com
Salut la liste,
Cette question s'adresse aux pros des langages et pourrait paraitre triviale pour ces derniers, veuillez m'excuser d'avance ;)
A la machine à café je me posais la question suivante : pour la future version de .NET (v4), notamment C# 4 et l'arrivée du dynamic, comment sont-ils arrivés à faire ça ?
la CLR est-elle remplacée totalement par la DLR ? mix des 2 ? DLR inclut dans la CLR ? autre ?
si une âme charitable pourrait m'expliquer en quelques mots le procédé - merci
Jb Evain
Aug 7, 2009, 8:05:31 AM8/7/09
to paris...@googlegroups.com
Yo,
On 8/7/09, DUVAL Olivier <zor...@gmail.com> wrote:
> A la machine à café je me posais la question suivante : pour la future
> version de .NET (v4), notamment C# 4 et l'arrivée du dynamic, comment
> sont-ils arrivés à faire ça ?
>
> la CLR est-elle remplacée totalement par la DLR ? mix des 2 ? DLR inclut
> dans la CLR ? autre ?
La DLR est juste un ensemble de classes managées sur lesquelles se
reposent les implémentations des langages dynamiques sur .net.
La DLR ne nécessite pas de changement de la CLR, elle fonctionne aussi
sur bien sur une CLR 2.0 qu'une CLR 4.0.
Quand on utilise le mot clef dynamic en C#4, le compilateur va ajouter
des appels à la librairie Microsoft.CSharp.dll, qui est une librairie
qui utilise la DLR pour faire communiquer le monde statique de C# avec
celui, et bien, dynamique, d'ailleurs.
Rien de bien compliqué, au final ;)
--
Jb Evain <j...@nurv.fr>
Mathias
Aug 7, 2009, 9:28:04 AM8/7/09
to altnetfr
C'est marrant de voir qu'un mot clef n'est plus une instruction bas
niveau, mais un raccourcie pour utiliser un framework.
C'est comme dans le langage Delphi Prism où le mot clef "async"
utilise "parallel extension" (voir http://prismwiki.codegear.com/en/Asynchronous_Statements
).
Ou les mots clefs "from where select.." qui utilisent linq...
J'ai découvert un truc dans le genre ou on peut même avoir des mots
clefs pour la validation d'une entité :
http://www.codeplex.com/NBusiness
http://www.justnbusiness.com/uploads/images/nbusiness-vsintegration.png
A une époque, j'étais vieux jeux, je préférais spécifier explicitement
les événements en Java à l'aide d'objets (classes anonymes).
Je faisais du vrai "Observer-Observable".
Car je n'aimais pas le fait que le mot clef "event" masque le fait que
c'est une liste d'événement.
Mais voila, tout ce qui raccourcie le langage me fait gagner du temps
à l'écriture, et me fait gagner du temps en explication avec certaines
personnes :)
niveau, mais un raccourcie pour utiliser un framework.
C'est comme dans le langage Delphi Prism où le mot clef "async"
utilise "parallel extension" (voir http://prismwiki.codegear.com/en/Asynchronous_Statements
).
Ou les mots clefs "from where select.." qui utilisent linq...
J'ai découvert un truc dans le genre ou on peut même avoir des mots
clefs pour la validation d'une entité :
http://www.codeplex.com/NBusiness
http://www.justnbusiness.com/uploads/images/nbusiness-vsintegration.png
A une époque, j'étais vieux jeux, je préférais spécifier explicitement
les événements en Java à l'aide d'objets (classes anonymes).
Je faisais du vrai "Observer-Observable".
Car je n'aimais pas le fait que le mot clef "event" masque le fait que
c'est une liste d'événement.
Mais voila, tout ce qui raccourcie le langage me fait gagner du temps
à l'écriture, et me fait gagner du temps en explication avec certaines
personnes :)
DUVAL Olivier
Aug 7, 2009, 10:28:35 AM8/7/09
to paris...@googlegroups.com
Merci Jb pour cette explication simple et claire - vivement 2010 ;)
2009/8/7 Jb Evain <j...@nurv.fr>
Think Before Coding
Aug 9, 2009, 4:51:53 PM8/9/09
to altnetfr
Pour bien comprendre en détail le fonctionnement de dynamic en C#4, tu
peux
lire 'C# in Depth 2' de John Skeet (editions Mannings)
http://www.manning.com/skeet2/
Quand tu déclare une variable dynamic, le compilateur va utiliser
une variable de type object, eventuellement marquée avec un attribut
(pour les fields, les arguments de méthode, les valeurs de retour
etc).
Pour toute oppération éffectuée sur cette variable, le compilateur
crée
un 'call site', un concept du DLR qui va se charger d'executer
l'opération
en question.
Quand C# crée un call site, il passe un binder C# (contenue dans
l'assembly
Microsoft.CSharp.dll) qui sera utilisé par le DLR pour éffectuer les
opérations
dynamic conformement au comportement classique de C# une fois les
types
résolus dynamiquement.
Si l'objet passé implemente IDynamicMetaObject, cet objet peut alors
interpreter
lui même l'appel dynamique effectué. L'implementation par defaut de
cette interface
(DynamicObject) laisse implmenenter des methodes telles que TryInvoke
(pour
les invocations de méthodes), TryGetMember pour les get sur les
propriétés etc.
Si l'objet est un objet .net qui n'implemente pas l'interface, le
binder tente simplement
de trouver une méthode qui correspond à l'appel demandé selon les
regles classiques
de résolution de surcharge de C#.
Sans forcement implementer IDynamicMetaObject, dynamic peut être très
utile
pour éviter tout un tas de relection lors des switchs sur les types
d'arguments.
Au lieu de :
void ConsumeMessage(Message message)
{
if (message is SomeMessage)
ConsumeMessage((SomeMessage)message);
else if (message is SomeOtherMessage)
ConsumeMessage((SomeOtherMessage)message);
else if (message is AnotherMessage)
ConsumeMessage((AnotherMessage)message);
}
ou des version avec beaucoup de Reflection pour créer un dictionnaire
de dispatch en fonction du type :
void ConsumeMessage(Message message)
{
IConsumer consumer;
if (!consumers.TryGetValue(message.GetType(), out conumer)
{
// crée un consumer par réflection à partir du type de message
pour appeler la bonne methode..
}
consumer.Consume(message);
}
on peut tout simplement faire :
void ConsumeMessage(Message message)
{
Consume((dynamic)message);
}
void Consume(SomeMessage m)
{
}
void Consume(SomeOtherMessage m)
{
}
void Consume(AnotherMessage m)
{
}
La ligne Consume((dynamic)message) va créer un call site de le but
sera d'appeler une methode nommée Consume prennant l'objet message
indiqué, ayant 3 overloads, le binder va déterminer celui qui convient
en fonction du type runtime du message.
Le compilateur est malin, si vous faite un appel qui quelque soient
les parametre ne pourra pas aboutir, il vous l'indiquera !
Je suis sur qu'on va vite trouver d'autres avantages à dynamic meme
sans pour autant faire de l'active record...
On 7 août, 16:28, DUVAL Olivier <zork...@gmail.com> wrote:
> Merci Jb pour cette explication simple et claire - vivement 2010 ;)
> 2009/8/7 Jb Evain <j...@nurv.fr>
>
>
>
>
>
>
>
> > Yo,
>
>
> - Afficher le texte des messages précédents -
peux
lire 'C# in Depth 2' de John Skeet (editions Mannings)
http://www.manning.com/skeet2/
Quand tu déclare une variable dynamic, le compilateur va utiliser
une variable de type object, eventuellement marquée avec un attribut
(pour les fields, les arguments de méthode, les valeurs de retour
etc).
Pour toute oppération éffectuée sur cette variable, le compilateur
crée
un 'call site', un concept du DLR qui va se charger d'executer
l'opération
en question.
Quand C# crée un call site, il passe un binder C# (contenue dans
l'assembly
Microsoft.CSharp.dll) qui sera utilisé par le DLR pour éffectuer les
opérations
dynamic conformement au comportement classique de C# une fois les
types
résolus dynamiquement.
Si l'objet passé implemente IDynamicMetaObject, cet objet peut alors
interpreter
lui même l'appel dynamique effectué. L'implementation par defaut de
cette interface
(DynamicObject) laisse implmenenter des methodes telles que TryInvoke
(pour
les invocations de méthodes), TryGetMember pour les get sur les
propriétés etc.
Si l'objet est un objet .net qui n'implemente pas l'interface, le
binder tente simplement
de trouver une méthode qui correspond à l'appel demandé selon les
regles classiques
de résolution de surcharge de C#.
Sans forcement implementer IDynamicMetaObject, dynamic peut être très
utile
pour éviter tout un tas de relection lors des switchs sur les types
d'arguments.
Au lieu de :
void ConsumeMessage(Message message)
{
if (message is SomeMessage)
ConsumeMessage((SomeMessage)message);
else if (message is SomeOtherMessage)
ConsumeMessage((SomeOtherMessage)message);
else if (message is AnotherMessage)
ConsumeMessage((AnotherMessage)message);
}
ou des version avec beaucoup de Reflection pour créer un dictionnaire
de dispatch en fonction du type :
void ConsumeMessage(Message message)
{
IConsumer consumer;
if (!consumers.TryGetValue(message.GetType(), out conumer)
{
// crée un consumer par réflection à partir du type de message
pour appeler la bonne methode..
}
consumer.Consume(message);
}
on peut tout simplement faire :
void ConsumeMessage(Message message)
{
Consume((dynamic)message);
}
void Consume(SomeMessage m)
{
}
void Consume(SomeOtherMessage m)
{
}
void Consume(AnotherMessage m)
{
}
La ligne Consume((dynamic)message) va créer un call site de le but
sera d'appeler une methode nommée Consume prennant l'objet message
indiqué, ayant 3 overloads, le binder va déterminer celui qui convient
en fonction du type runtime du message.
Le compilateur est malin, si vous faite un appel qui quelque soient
les parametre ne pourra pas aboutir, il vous l'indiquera !
Je suis sur qu'on va vite trouver d'autres avantages à dynamic meme
sans pour autant faire de l'active record...
On 7 août, 16:28, DUVAL Olivier <zork...@gmail.com> wrote:
> Merci Jb pour cette explication simple et claire - vivement 2010 ;)
> 2009/8/7 Jb Evain <j...@nurv.fr>
>
>
>
>
>
>
>
> > Yo,
>
> > On 8/7/09, DUVAL Olivier <zork...@gmail.com> wrote:
> > > A la machine à café je me posais la question suivante : pour la future
> > > version de .NET (v4), notamment C# 4 et l'arrivée du dynamic, comment
> > > sont-ils arrivés à faire ça ?
>
> > > la CLR est-elle remplacée totalement par la DLR ? mix des 2 ? DLR
> > inclut
> > > dans la CLR ? autre ?
>
> > La DLR est juste un ensemble de classes managées sur lesquelles se
> > reposent les implémentations des langages dynamiques sur .net.
>
> > La DLR ne nécessite pas de changement de la CLR, elle fonctionne aussi
> > sur bien sur une CLR 2.0 qu'une CLR 4.0.
>
> > Quand on utilise le mot clef dynamic en C#4, le compilateur va ajouter
> > des appels à la librairie Microsoft.CSharp.dll, qui est une librairie
> > qui utilise la DLR pour faire communiquer le monde statique de C# avec
> > celui, et bien, dynamique, d'ailleurs.
>
> > Rien de bien compliqué, au final ;)
>
> > --
> > Jb Evain <j...@nurv.fr>
>
> --
> Olivier DUVALhttp://olivier-duval.info- Masquer le texte des messages précédents -
> > > A la machine à café je me posais la question suivante : pour la future
> > > version de .NET (v4), notamment C# 4 et l'arrivée du dynamic, comment
> > > sont-ils arrivés à faire ça ?
>
> > > la CLR est-elle remplacée totalement par la DLR ? mix des 2 ? DLR
> > inclut
> > > dans la CLR ? autre ?
>
> > La DLR est juste un ensemble de classes managées sur lesquelles se
> > reposent les implémentations des langages dynamiques sur .net.
>
> > La DLR ne nécessite pas de changement de la CLR, elle fonctionne aussi
> > sur bien sur une CLR 2.0 qu'une CLR 4.0.
>
> > Quand on utilise le mot clef dynamic en C#4, le compilateur va ajouter
> > des appels à la librairie Microsoft.CSharp.dll, qui est une librairie
> > qui utilise la DLR pour faire communiquer le monde statique de C# avec
> > celui, et bien, dynamique, d'ailleurs.
>
> > Rien de bien compliqué, au final ;)
>
> > --
> > Jb Evain <j...@nurv.fr>
>
> --
>
> - Afficher le texte des messages précédents -
DUVAL Olivier
Aug 10, 2009, 8:53:15 AM8/10/09
to paris...@googlegroups.com
merci TBC (Jérémie je crois) - pas mal je trouve, et en effet de s'approcher d'ActiveRecord (de Rails j'entends), je suppose que tu fais référence au billet suivant : http://bugsquash.blogspot.com/2009/05/rails-like-finders-for-nhibernate-with.html
nous qui nous plaignons d'avoir trop de méthodes Find (FindByName, ByColors, Bylaterreentiere) et autres joyeusetés, j'aime bien personnellement, ça laisse pas mal de possibilité ce dynamic (les puristes du compilé vont crier au scandale je sens ;-))
2009/8/9 Think Before Coding <jeremie....@thinkbeforecoding.com>
Sebastien Crocquesel
Aug 10, 2009, 1:48:11 PM8/10/09
to paris...@googlegroups.com
J'étais parti sur un même genre d'idée mais sur les propriétés. L'idée était d'avoir une classe avec un dictionnaire et le remplir en accédant par des propriétés "dynamiques". Un peu comme ce que propose php et les magic method __set __get.
L'idée était d'utiliser cela avec asp.net MVC au niveau des vues et d'avoir quelques choses de semblable au mécanisme d'échange entre la vue et le controlleur de ZendFramework. Ca évite quand on a plusieurs variables distinctes à passer, d'avoir recourt à l'écriture d'une classe "Conteneur" comme Modèle de la vue.
Une autre idée, serait de simplifier la navigation xml aussi en permettant une notation fluant sans avoir recours à des classes additionnelles serializables.
Voilà pour mes idées, si y'en a d'autres, je suis preneur :p
Denis Dollfus
Aug 11, 2009, 6:29:21 PM8/11/09
to altnetfr
@Olivier :
Certainement les puristes du compilé vont crier au scandale, et
certainement les aficionados du full dynamique vont se répandre en
articles apologétiques plein de points d'exclamations. Entre les deux
il y a de la place pour considérer au cas par cas les avantages et
inconvénients des deux approches, et les ALTernatives ;-)
L'exemple de Jérémie me semble être un cas où le mot-clé dynamic
apporte un plus. Dans d'autres cas (je n'ai pas dit dans tous les cas)
le risque d'avoir des erreurs au runtime (chez le client forcément :)
prend le dessus, et ce malgré les test unitaires. Déjà que compilo +
tests unitaires laisse des erreurs chez le client... Mais c'est un
risque qui peut être calculé et mis en balance avec les gains en
productivité (ou autres ?).
Côté inconvénient je vois aussi les bâtons que les variables
dynamiques vont mettre dans les roues des outils de refactoring
(resharper ou VS) et d'Intellisense. Perte de productivité qui annule
les gains ?
C'est une vraie question, je ne connais "dynamic" que par ce tread, le
buzz et cette page http://msdn.microsoft.com/en-us/library/dd264736(VS.100).aspx.
Voilà moi aussi je détourne les threads, j'espère que les puristes du
non-détournement de threads ne vont pas crier au scandale...
Denis
On 10 août, 14:53, DUVAL Olivier <zork...@gmail.com> wrote:
> merci TBC (Jérémie je crois) - pas mal je trouve, et en effet de s'approcher
> d'ActiveRecord (de Rails j'entends), je suppose que tu fais référence au
> billet suivant :http://bugsquash.blogspot.com/2009/05/rails-like-finders-for-nhiberna...
> > > Olivier DUVALhttp://olivier-duval.info-Masquer le texte des messages
Certainement les puristes du compilé vont crier au scandale, et
certainement les aficionados du full dynamique vont se répandre en
articles apologétiques plein de points d'exclamations. Entre les deux
il y a de la place pour considérer au cas par cas les avantages et
inconvénients des deux approches, et les ALTernatives ;-)
L'exemple de Jérémie me semble être un cas où le mot-clé dynamic
apporte un plus. Dans d'autres cas (je n'ai pas dit dans tous les cas)
le risque d'avoir des erreurs au runtime (chez le client forcément :)
prend le dessus, et ce malgré les test unitaires. Déjà que compilo +
tests unitaires laisse des erreurs chez le client... Mais c'est un
risque qui peut être calculé et mis en balance avec les gains en
productivité (ou autres ?).
Côté inconvénient je vois aussi les bâtons que les variables
dynamiques vont mettre dans les roues des outils de refactoring
(resharper ou VS) et d'Intellisense. Perte de productivité qui annule
les gains ?
C'est une vraie question, je ne connais "dynamic" que par ce tread, le
buzz et cette page http://msdn.microsoft.com/en-us/library/dd264736(VS.100).aspx.
Voilà moi aussi je détourne les threads, j'espère que les puristes du
non-détournement de threads ne vont pas crier au scandale...
Denis
On 10 août, 14:53, DUVAL Olivier <zork...@gmail.com> wrote:
> merci TBC (Jérémie je crois) - pas mal je trouve, et en effet de s'approcher
> d'ActiveRecord (de Rails j'entends), je suppose que tu fais référence au
>
> nous qui nous plaignons d'avoir trop de méthodes Find (FindByName, ByColors,
> Bylaterreentiere) et autres joyeusetés, j'aime bien personnellement, ça
> laisse pas mal de possibilité ce dynamic (les puristes du compilé vont crier
> au scandale je sens ;-))
>
> 2009/8/9 Think Before Coding <jeremie.chassa...@thinkbeforecoding.com>
> nous qui nous plaignons d'avoir trop de méthodes Find (FindByName, ByColors,
> Bylaterreentiere) et autres joyeusetés, j'aime bien personnellement, ça
> laisse pas mal de possibilité ce dynamic (les puristes du compilé vont crier
> au scandale je sens ;-))
>
DUVAL Olivier
Aug 12, 2009, 4:32:02 AM8/12/09
to paris...@googlegroups.com
on a toujours eu des batailles de clochers (.NET / Java, Opensource / propriétaires, Windows / Linux, compilé / interprété), mais tout ça, n'est-ce pas pour avancer un peu ;)
les tests devraient diminuer le risque, mais ne le rend pas nul, c'est vrai - sans le dynamic, c'était déjà le cas, qui n'a jamais utilisé : ArrayList, la reflection, des FindControl [en ASP.NET Webforms ] et autres méthodes pour résoudre des choses dynamiquement, ce n'est pas forcément très joli mais on est toujours confronté à la réalité, suffit d'en être conscient et de ne pas abuser. Pour les R# et autres, en effet, c'est gênant, faisons leur confiance pour trouver une parade.
MS innove tellement dans son framework, à chaque nouvelle version son lot d'avancées, c'est vraiment extra, dur à suivre par moment, mais facilite tellement la vie.
vais de ce pas parler de ce langage compilé qui devient maintenant (un peu) interprété à mon DSI ;)
2009/8/12 Denis Dollfus <denis....@gmail.com>
Romain Verdier
Aug 12, 2009, 4:34:00 AM8/12/09
to altnetfr
Un moyen simple de ne pas se tromper -- au risque quand même de sous-
exploiter le mécanisme -- est de considérer l'utilisation de "dynamic"
sans risque lorsque vous auriez dû de toute façon faire impasse sur le
typage fort, l'intellisense, etc.
Exemple avec la réflexion :
var lol = new Lol();
var roflInfo = typeof(Lol).GetProperty("Rofl");
roflInfo.SetValue(lol, "haha", null);
Exemple avec dynamic :
dynamic lol = new Lol();
lol.Rofl = "haha";
Dans les deux cas, au design-time, on suppose l'existence de la
propriété "Rofl", mais ni la compilation ni l'intellisense ne nous
aident. L'utilisation de dynamic dans cet exemple apporte une
meilleure lisibilité/concision, et offre de meilleures performances
dans le cas où il faudrait affecter/lire la propriété de nombreuses
fois.
Romain
On Aug 12, 12:29 am, Denis Dollfus <denis.doll...@gmail.com> wrote:
> @Olivier :
>
> Certainement les puristes du compilé vont crier au scandale, et
> certainement les aficionados du full dynamique vont se répandre en
> articles apologétiques plein de points d'exclamations. Entre les deux
> il y a de la place pour considérer au cas par cas les avantages et
> inconvénients des deux approches, et les ALTernatives ;-)
>
> L'exemple de Jérémie me semble être un cas où le mot-clé dynamic
> apporte un plus. Dans d'autres cas (je n'ai pas dit dans tous les cas)
> le risque d'avoir des erreurs au runtime (chez le client forcément :)
> prend le dessus, et ce malgré les test unitaires. Déjà que compilo +
> tests unitaires laisse des erreurs chez le client... Mais c'est un
> risque qui peut être calculé et mis en balance avec les gains en
> productivité (ou autres ?).
>
> Côté inconvénient je vois aussi les bâtons que les variables
> dynamiques vont mettre dans les roues des outils de refactoring
> (resharper ou VS) et d'Intellisense. Perte de productivité qui annule
> les gains ?
>
> C'est une vraie question, je ne connais "dynamic" que par ce tread, le
> buzz et cette pagehttp://msdn.microsoft.com/en-us/library/dd264736(VS.100).aspx.
> > > > Olivier DUVALhttp://olivier-duval.info-Masquerle texte des messages
exploiter le mécanisme -- est de considérer l'utilisation de "dynamic"
sans risque lorsque vous auriez dû de toute façon faire impasse sur le
typage fort, l'intellisense, etc.
Exemple avec la réflexion :
var lol = new Lol();
var roflInfo = typeof(Lol).GetProperty("Rofl");
roflInfo.SetValue(lol, "haha", null);
Exemple avec dynamic :
dynamic lol = new Lol();
lol.Rofl = "haha";
Dans les deux cas, au design-time, on suppose l'existence de la
propriété "Rofl", mais ni la compilation ni l'intellisense ne nous
aident. L'utilisation de dynamic dans cet exemple apporte une
meilleure lisibilité/concision, et offre de meilleures performances
dans le cas où il faudrait affecter/lire la propriété de nombreuses
fois.
Romain
On Aug 12, 12:29 am, Denis Dollfus <denis.doll...@gmail.com> wrote:
> @Olivier :
>
> Certainement les puristes du compilé vont crier au scandale, et
> certainement les aficionados du full dynamique vont se répandre en
> articles apologétiques plein de points d'exclamations. Entre les deux
> il y a de la place pour considérer au cas par cas les avantages et
> inconvénients des deux approches, et les ALTernatives ;-)
>
> L'exemple de Jérémie me semble être un cas où le mot-clé dynamic
> apporte un plus. Dans d'autres cas (je n'ai pas dit dans tous les cas)
> le risque d'avoir des erreurs au runtime (chez le client forcément :)
> prend le dessus, et ce malgré les test unitaires. Déjà que compilo +
> tests unitaires laisse des erreurs chez le client... Mais c'est un
> risque qui peut être calculé et mis en balance avec les gains en
> productivité (ou autres ?).
>
> Côté inconvénient je vois aussi les bâtons que les variables
> dynamiques vont mettre dans les roues des outils de refactoring
> (resharper ou VS) et d'Intellisense. Perte de productivité qui annule
> les gains ?
>
> C'est une vraie question, je ne connais "dynamic" que par ce tread, le
Think Before Coding
Aug 12, 2009, 4:10:13 PM8/12/09
to altnetfr
Oui, dans beaucoup de cas où on passait par de la reflection, le
travail risque
d'etre pas mal simplifié et beaucoup plus performant, c'est déjà pas
mal.
A mon avis, pour pas trop perdre en sécurité, il faudra se réstreindre
à utiliser
dynamic dans des parties closes du code - par là j'entends derriere
des façaces
fortement types, ou en tout cas bien controllées.
Je ne sais pas comment R# va gérer ça, mais IDynamicMetaObject peut
renvoyer
des infos de typage.. j'ai pas encore regardé ca en détail.
Ca va être très pratique aussi pour l'usage des opérateurs
arithmétiques dans les
méthodes génériques.
On va enfin pouvoir ecrire :
T Sum<T>(IEnumerable<T> source)
{
dynamic sum = default(T);
foreach (T value in source)
sum += value;
return (T)sum;
}
et hop !
> > > > > Olivier DUVALhttp://olivier-duval.info-Masquerletexte des messages
travail risque
d'etre pas mal simplifié et beaucoup plus performant, c'est déjà pas
mal.
A mon avis, pour pas trop perdre en sécurité, il faudra se réstreindre
à utiliser
dynamic dans des parties closes du code - par là j'entends derriere
des façaces
fortement types, ou en tout cas bien controllées.
Je ne sais pas comment R# va gérer ça, mais IDynamicMetaObject peut
renvoyer
des infos de typage.. j'ai pas encore regardé ca en détail.
Ca va être très pratique aussi pour l'usage des opérateurs
arithmétiques dans les
méthodes génériques.
On va enfin pouvoir ecrire :
T Sum<T>(IEnumerable<T> source)
{
dynamic sum = default(T);
foreach (T value in source)
sum += value;
return (T)sum;
}
et hop !
> > > > précédents -
>
> > > > > - Afficher le texte des messages précédents -
>
> > > --
> > > Olivier DUVALhttp://olivier-duval.info- Masquer le texte des messages précédents -
>
> > > > > - Afficher le texte des messages précédents -
>
> > > --
Reply all
Reply to author
Forward
0 new messages