Recommandé
Contenu connexe
Tendances
Tendances (19)
Similaire à As Novidades do C# 4.0
Similaire à As Novidades do C# 4.0 (20)
Plus de Paulo Morgado
Plus de Paulo Morgado (16)
As Novidades do C# 4.0
- 1. As Novidades Do C#
- 3. A Evolução ao C# Covariância e Contravariância Argumentos com Nome e Opcionais Programação Dinâmica Melhoramentos na Interoperabilidade com COM Agenda
- 4. A Evolução do C#
- 5. A Evolução do C#
- 6. Tendências
- 13. Inicializadores de colecçõesC# C# VB Co-Evolução
- 14. A Evolução do C#
- 15. A evolução do C# http://paulomorgado.net/pt/blog/archive/2010/04/12/a-evolu-231-227-o-do-c.aspx Recursos
- 17. Em álgebra multilinear, covariância e contravariância descrevem como a descrição quantitativa de certas entidades geométricas ou físicas variam quando passam de um sistema de coordenadas para outro. Wikipedia Covariância e Contravariância
- 18. O tipo T é maior (>) que o tipo S se S é um subtipo (deriva) de T Covariância e Contravariância T≥S typeof(T).IsAssignableFrom(typeof(S))
- 19. Dados 2 tipos Base e Derivado, em que: Existe uma conversão por referência (ou identidade) entre Base e Derivado Base ≥ Derived Uma definição de tipo genérico Genérico<T> é: Covariante em T Se Genérico<Base> ≥ Genérico<Derivado> Contravariante em T Se Genérico<Base> ≤ Genérico<Derivado> Invariante em T Se nenhuma das regras anteriores se aplica Covariância e Contravariância
- 20. Contravariante em T Covariante em T typeof(Base).IsAssignableFrom(typeof(Derivado)) typeof(Base).IsAssignableFrom(typeof(Derivado)) typeof(G<Derivado>).IsAssignableFrom(typeof(G<Base>)) typeof(G<Base>).IsAssignableFrom(typeof(G<Derivado>)) Covariância e Contravariância
- 21. Covariância e Contravariância EmC# (.NET), osarrayssãocovariantes string[] strings = GetStringArray(); Process(strings); …mas nãosãocovariantesseguros void Process(object[] objects) { … } void Process(object[] objects) { objects[0] = "Hello"; // Ok objects[1] = newButton(); // Exception! }
- 22. Covariância e Contravariância Até agora, no C# (.NET), osgenéricostêmsidoinvariantes List<string> strings = GetStringList(); Process(strings); O C# 4.0suporta covariância e contravariânciasegura void Process(IEnumerable<object> objects) { // IEnumerable<T> é apenas de leitura // portanto é covarianteseguro } void Process(IEnumerable<object> objects) { … }
- 23. Covariância Segura out= covarianteapenasemposições de saída publicinterfaceIEnumerable<T> { IEnumerator<T> GetEnumerator(); } publicinterfaceIEnumerable<out T> { IEnumerator<T> GetEnumerator(); } Podesertratadocomo menosderivado publicinterfaceIEnumerator<T> { T Current { get; } boolMoveNext(); } publicinterfaceIEnumerator<out T> { T Current { get; } boolMoveNext(); } IEnumerable<string> strings = GetStrings(); IEnumerable<object> objects = strings;
- 24. Contravariância Segura in= contravarianteapenasemposições de entrada Podesertratadocomomaisderivado publicinterfaceIComparer<T> { int Compare(T x, T y); } publicinterfaceIComparer<in T> { int Compare(T x, T y); } IComparer<object> objComp = GetComparer(); IComparer<string> strComp = objComp;
- 25. Suportada apenas para interfaces genéricas e delegates genéricos. Verificada/forçada estáticamente a partir da definição. Tipos valor são sempre invariantes Um IEnumerable<int> não é um IEnumerable<object> A regra para arrays é similar Parâmetros ref e out necessitam tipos parâmetros invariantes Variância em C# 4.0
- 26. Variância em .NET 4.0
- 27. Covariância E Contravariância Em Genéricos http://paulomorgado.net/pt/blog/archive/2010/04/13/c-4-0-covari-226-ncia-e-contravari-226-ncia-em-gen-233-ricos.aspx Covariância E Contravariância Em Genéricos – Simplificado http://paulomorgado.net/pt/blog/archive/2010/04/15/c-4-0-covari-226-ncia-e-contravari-226-ncia-em-gen-233-ricos-simplificado.aspx Covarince and Contravariance in Generics http://msdn.microsoft.com/library/dd799517(VS.100).aspx Exact rules for variance validity http://blogs.msdn.com/ericlippert/archive/2009/12/03/exact-rules-for-variância-validity.aspx Events get a little overhaul in C# 4, Afterward: Effective Events http://blogs.msdn.com/cburrows/archive/2010/03/30/events-get-a-little-overhaul-in-c-4-afterward-effective-events.aspx Recursos
- 28. Argumentos com Nome e Opcionais
- 29. Argumentos com Nome e Opcionais Greeting("Mr.", "Morgado", 42); Parâmetros Argumentos public void Greeting(string title, string name, intage) Têmsemprenome Nuncasãoopcionais
- 30. Argumentos com Nome int i = 0; Method(i, third: i++, second: ++i); int i = 0; int CS$0$0000 = i++; int CS$0$0001 = ++i; Method(i, CS$0$0001, CS$0$0000); public void Method(intfirst, intsecond, intthird)
- 31. Argumentos Opcionais int i = 0; Method(i, third: ++i); int i = 0; int CS$0$0000 = ++i; Method(i, 2, CS$0$0000); public void Method(intfirst, intsecond = 5, intthird = 6) public void Method(intfirst, intsecond = 2, intthird = 3) public void Method(intfirst, intsecond) Parecem sobreposições (overloads) Mas nãosão! public void Method(intfirst)
- 32. Classes de Argumentos Argumentos Opcionais - Alternativa XmlReaderSettings settings = newXmlReaderSettings(); settings.ValidationType = ValidationType.Auto; XmlReader.Create("file.xml", settings); XmlReader.Create( "file.xml", new { ValidationType = ValidationType.Auto }); XmlReader.Create( "file.xml", newXmlReaderSettings { ValidationType = ValidationType.Auto }); Aindanão!
- 33. Argumentos Com Nome E Opcionais http://paulomorgado.net/pt/blog/archive/2010/04/16/c-4-0-argumentos-com-nome-e-opcionais.aspx Alternativa Aos Argumentos Opcionais http://paulomorgado.net/pt/blog/archive/2010/04/18/c-4-0-alternativa-aos-argumentos-opcionais.aspx Named and Optional Arguments (C# Programming Guide) http://msdn.microsoft.com/library/dd264739(VS.100).aspx Recursos
- 35. Dynamic Language Runtime IronPython IronRuby C# VB.NET Others… Dynamic Language Runtime Expression Trees Dynamic Dispatch Call Site Caching PythonBinder RubyBinder COMBinder JavaScriptBinder ObjectBinder
- 36. Objectos Tipados Dinâmicamente Calculatorcalculator = GetCalculator(); int sum = calc.Add(10, 20); object calculator = GetCalculator(); Type calculatorType = calculator.GetType(); object res = calculatorType.InvokeMember("Add", BindingFlags.InvokeMethod, null, calculator, newobject[] { 10, 20 }); int sum = Convert.ToInt32(res); ScriptObject calculator = GetCalculator(); object res = calculator.Invoke("Add", 10, 20); int sum = Convert.ToInt32(res); Estaticamente tipado paraserdinâmico dynamic calc = GetCalculator(); int sum = calc.Add(10, 20); Invocação de métododinâmica Conversãodinâmica
- 38. Em tempo de execução, ostiposreaissãosubstituídospordynamic
- 40. IDynamicMetaObjectProvider Representa um objecto dinâmico que pode ter operações determinadas em tempo de execução. DynamicObject : IDynamicMetaObjectProvider Permite definir o comportamento do objecto dinâmico quando se pretende executar uma operação. ExpandoObject : IDynamicMetaObjectProvider Objecto que permite que lhe sejam adicionados e removidos membros. Construção de Objectos Dinâmicos
- 41. Programação Dinâmica http://paulomorgado.net/pt/blog/archive/2010/04/18/c-4-0-programa-231-227-o-din-226-mica.aspx Proposta C#: Verificação Estática De Objectos Dinâmicos Em Tempo De Compilação http://paulomorgado.net/pt/blog/archive/2010/03/17/proposta-c-verifica-231-227-o-est-225-tica-de-objectos-din-226-micos-em-tempo-de-compila-231-227-o.aspx Using Type dynamic (C# Programming Guide) http://msdn.microsoft.com/library/dd264736(VS.100).aspx Dynamic Language Runtime Overview http://msdn.microsoft.com/library/dd233052(v=VS.100).aspx Recursos
- 42. Melhoramentos na Interoperabilidade com COM
- 43. Argumentos com nome e opcionais Omissão do Modificador ref Importação Dinâmica Mapeamento automático object -> dynamic Propriedades indexadas Equivalência de Tipos e Tipos Embebidos (“NO PIA”) Melhoramentos na Interoperabilidade com COM
- 44. Omissão do Modificador ref objectfileName = "Test.docx"; object missing = Missing.Value; document.SaveAs(reffileName, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing, ref missing); document.SaveAs("Test.docx", Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value, Missing.Value); document.SaveAs("Test.docx");
- 45. Importação Dinâmica ((Excel.Range)(excel.Cells[1, 1])).Value2 = "Hello World!"; excel.Cells[1, 1] = "Hello World!"; Excel.Range range = (Excel.Range)(excel.Cells[1, 1]); Excel.Rangerange = excel.Cells[1, 1];
- 46. Equivalência de Tipos e TiposEmbebidos (NO PIA)
- 47. Melhoramentos Para Interoperabilidade Com COM http://paulomorgado.net/pt/blog/archive/2010/04/19/c-4-0-melhoramentos-para-interoperabilidade-com-com.aspx Type Equivalence and Embedded InteropTypes http://msdn.microsoft.com/library/dd997297.aspx Recursos
- 48. Demos
- 50. Conclusão
- 51. A Evolução ao C# Covariância e Contravariância Argumentos com Nome e Opcionais Programação Dinâmica Melhoramentos na Interoperabilidade com COM Conclusão
- 52. Visual C# Developer Center http://csharp.net/ Visual C# 2010 Samples http://code.msdn.microsoft.com/cs2010samples C# Language Specification 4.0 http://www.microsoft.com/downloads/details.aspx?familyid=DFBF523C-F98C-4804-AFBD-459E846B268E&displaylang=en Recursos
- 53. .NET Reflector http://www.red-gate.com/products/reflector/ LINQPad http://linqpad.net/ Paulo Morgado http://PauloMorgado.NET/ Recursos
- 54. Obrigado!
Notes de l'éditeur
- A primeira versão do C# (C# 1.0) foi, essencialmente, o desenvolvimento de uma linguagem de programação para código gerido (managed code) que apelasse, pricipalmente, a programadores de C++ e Java.Com a segunda versão (C# 2.0) pretendeu-se colmatar as falhas da primeria versão adicionado o que não tinha tido tempo de ser incluído. A principal funcionalidade desta versão foram os Genéricos.Na terceira versão (C# 3.0) pretendeu-se reduzir a dissonância entre as linguagens de programação de uso geral e as base de dados. Para alcaçar este objectivo, foram adicionadas algumas funcionalidades da programação funcional e nascia o LINQ.
- Novas tendências estão a aparecer na industria e as linguagens de programação modernas necessitam de ser mais:DeclarativasCom as linguagens imperativas, mesmo sem deixar de ter em conta o quê, os programas têm de se focar no como. Isto leva à sobre-especificação da solução para o problema em mãos, tornando praticamente impossível ao motor de execução ser suficientemente esperto para optimizar a execução do programa e executá-lo mais eficientemente (parar o hardware disponível, por exemplo).As linguagens declarativas, por outro lado, focam-se no quê e deixam o como ao motor de execução. O LINQ tornou o C# mais declarativo usando instrucções de alto nível como orderby e group by que dão ao motor de execução mais chances de uma melhor optimização da execução (paralelizando-a, por exemplo).ConcorrentesA concorrência é muito difícil e necessita de ser bem pensada o que a torna muito difícil de “enfiar” numa linguagem de programação. O Parallel.For (das parallel extensions) tem o aspecto de um for paralelo porque foi dada suficiente expressividade ao C# 3.0 para permitir utilizações destas sem ter se usar uma sintaxe específica da linguagem.DinâmicasTem havido muito debate acerca qual o melhor tipo de linguagem de programação: estaticas or dinâmicas. O facto é que ambas têm boas qualidades e os utilizadores de ambas querem ter todas as funcionalidades à sua disposição.Todas estas novas tendências requerem uma mudança de paradigma. O C# já é, em muitos aspectos, uma linguagem multi-paradigma. Ainda é uma linguagem muito orientada a objectos (ou a classes, segundo algumas opiniões), mas pode-se argumentar que o C# 3.0 se tornou uma linguagem de programação funcional porque tem todas as bases do que uma linguagem de programação funcional necessita. De futuro, terá ainda mais.
- Além da influência destas tendências, houve uma decisão de co-evolução das linguagens de programação C# e Visual Basic. Desde o início que tem havido algum esforço em posicionar o C# e o Visual Basic em campos contrários e tentativas de justificar o que deve ser feito como uma ou outra linguagem de programação. Cada linguagem deve ser excolhida de de acordo com a experiência e familiaridade de programadores/equipas/projectos/empresas e não por qualquer funcionalidade em particular.No passado, sempre que uma nova funcionalidade era adicioanda a uma das linguagens, os utilizadores da outra também a queriam para a sua lingaugem de opção. De futuro, sempre que uma funcionalidade for adicionada a uma das linguagens, a outra fará todos os esforços para também a adicionar. Ist não quer dizer que os literais XML serão adicionados ao C# (porque se pode obter quase o mesmo com o LINQ To XML), mas o Visual Basic terá propriedades auto-implementadas.A quase totalidade destas funcionalidades requer ou é construída sobre funcionalidades da .NET Framework e, o foco para o C# 4.0 foi a rogramação dinâmica. Não apenas tipos dinâmicos, mas a capacidade de falar com qualquer coisa que não seja uma classe.NET.Também introduzido com C# 4.0 é a co-variância e contra-variância para interfaces e delegates genéricos.
- O C# 4.0 (e a .NET 4.0) introduziram covariância e contravariância em interfaces e delegates genericos. Mas afinal o que é a variância?Segundo a Wikipedia, em álgebra multilinear, covariância e contravariância descrevem como a descrição quantitativa de certas entidades geométricas ou físicas variam quando passam de um systema de coordenadas para outro.(*)
- Mas o que é que isto tem a ver com C# ou .NET?Na teoria de tipos, um tipo T é maior (>) que o tipo S se S é um subtipo (deriva) de T, o que quer dizer que existe uma descrição quantitativa para tipos numa hierarquia de tipos.Sendo assim, como é que a covariância e a contravariância se aplicam aos tipos genéricos do C# (e de .NET)?Em C# (e em .NET), variância é uma relação entre uma definição de tipo genérico e um determinado tipo parâmetro de genéricos.Dados dois tipos Base e Derivado, em que:Existe uma conversão por referência (ou identidade) entre Base e DerivadoBase ≥ Derivado
- Uma definição de tipo genérico Genérico<T> é:covariante em T se a ordem dos tipos construídos segue a ordem dos tipos parâmetros de genéricos : Genérico<Base> ≥ Genérico<Derivado>contravariante em T se a ordem dos tipos construídos é inversa à ordem dos tipos parâmetros de genéricos : Genérico<Base> ≤ Genérico<Derivado>invariante em T se nenhuma das regras acima se aplica.
- Se aplicarmos a definição a arrays, podemos constatar que os arrays sempre foram covariantes porque este código é válido:object[] objectArray = new string[] { "string 1", "string 2" };objectArray[0] = "string 3";objectArray[1] = new object();Contudo, quando tentamos correr este código, a segunda afectação vai lançar uma ArrayTypeMismatchException. Apesar do compilador ter sido enganado para pensar que o código era válido porque um object está a ser atribuído a um elemento de um array de object, em tempo de execução, há sempre uma verificação de tipos para garantir que o tipo em tempo de execução da definição dos elementos do array é maior ou igual ao da instância quie está a ser atribuída ao elemento. No exemplo acima, porque o tipo em tempo de execução é array de string, a primeira afectação de elementos é válida porque string ≥string e a segunda não é válida porque string ≤object.Isto leva-nos à conclusão de que, apesar dos arrays sempre terem sido covariantes, não são covariantes sem riscos – não é garantido que código que compila corra sem erros.
- Em C#, a variância em relação um determinado tipo parâmetro de genéricos é forçada na declaração e não determinada pelo uso desse tipo parâmero de genéricos.A covariância em relação a um determinado tipo parâmetro de genéricos é forçada através do modificador genérico outNote-se o conveniente uso da palavra reservada out já existente. Além do benefício de não nos termos de lembrar de uma nova hipotética palavra reservada covariant, out (saída) é mais fácil de lembrar porque define que o tipo parâmetro de genéricos apenas pode ser usando em posições de saída — propriedades apenas de leitura e valores de saída de métodos.
- Similarmente, a contravariância em relação a um determinado tipo parâmetro de genéricos é forçada através do modificador genérico inMais uma vez, o uso da palavra reservada in (entrada) já existente é mais fácil de lembrar keyporque define que o tipo parâmetro de genéricos apenas pode ser usando em posições de entrada — propriedades apenas de escrita e parâmetros de métodos que não sejam por referência (ref) nem de saída (out).
- Um tipo parâmetro de genéricos que não seja marcado covariante (out) ou contravariante (in) é invariante.Porque a variância se aplica à relação entre uma definição de tipo genérico e um determinado tipo parâmetro de genéricos, uma definição de tipo genérico pode ser covariante, contravariante, invariante dependendo do tipo parâmetro genérico.Na definição do delegate genérico acima, Func<T, TResult> é contravariant em T e convariante em TResult.Em resumo, as regras da variância em C# (e .NET) são:A variância em relação a tipos parâmetros de genéricos está restringida aos tipos interfaces genéricas e delegates genéricos.Uma interface genérica ou um delegate genérico podem ser, em simultâneo covariante, contravariante ou invariante em relação a diferentes tipos parâmetros de genéricos.A variância aplica-se apenas a tipos referência: um IEnumerable<int> não é um IEnumerable<object>.A variância não se aplica à combinação de delegates. Isto é, dados dois delegates do tipo Action<Derived> e Action<Base>, não é possível combinar o segundo delegate com o primeiro apesar de que o resulado ser seguro do ponto de vista do tipo. A variância permite que o segundo delegate seja atribuído a uma variável do tipo Action<Derived>, mas os delegates apenas podem ser combinados se os seus tipos forem uma correspondência exacta.
- Todos os tipos da .NET Framework onde a variância podia ser aplicada foram alterados para que os seus tipos parâmetros de genéricos pudessem tirar partido desta funcionalidade.
- Como parte do esforço de co-evolução do C# e do Visual Basic, o C# 4.0 introduz Argumentos com Nome e Opcionais.Primeiro clarifiquemos o que são argumentos e o que são parâmetros:Os parâmetros da definição de um método são as variáveis de entrada do método.Os argumentos da declaração da chamada a um método são os valores providenciados para os .De facto, a Especificação da Linguagem C# afirma em §7.5 que:A lista de argumentos (§7.5.1) da invocação de um membro função providencia os valores que vão ser efectivamente usados como variáveis ou referências a variáveis como parâmetros do membro função.Dadas as definições acima, podemos afirmar que:Os parâmetros sempre tiveram, e continua a ter, nome.Os parâmetros nunca foram, e continuam a não ser, opcionais.
- Até agora, a forma como o compilador de C# fazia corresponder os argumentos da declaração de uma chamada a um método era pela sua posição. O primeiro argumento providencia o valor para o primeiro parâmetro o segundo argumento providencia o valor para o segundo parâmetro, e por aí fora, independentemente do número de parâmetros. Se algum parâmetro não tivesse um argumento correspondente para lhe providenciar o valor, isso faria o compilador emitir um erro de compilação.Para esta chamada:Greeting("Mr.", "Morgado", 42); este métdo:public void Greeting(string title, string name, int age)receberá como parâmetros:title: “Mr.”name: “Morgado”age: 42O que esta nova funcionalidade permite é usar os nomes dos parâmteros para identificar os argumentos correspondentes na forma: name:valueNem todos os argumentos da lista precisam de ser identificados com o nome do correspondente parâmetros. No entanto, todos os argumentos com nome devem ser posicionados no fim da lista de argumentos. A correspondência entre os argumentos (e a avaliação do seu valor) e os parâmetros será feita primeiro pelo nome dos argumentos com nome (apesar destes se encontrarem no fim da lista) e em seguida pela posição, para os parâmteros para os quais ainda não foi atribuído valor.Isto quer dizer que, para esta definição de método:public void Method(int first, int second, int third) esta declaração de chamada:int i = 0; Method(i, third: i++, second: ++i); terá o seguinte código gerado pelo compilador:int i = 0; int CS$0$0000 = i++; int CS$0$0001 = ++i; Method(i, CS$0$0001, CS$0$0000);o que dará aos parâmetros do método os seguintes valores:first: 2 second: 2 third: 0 Note-se que os nomes das variáveis geradas pelo compilador não são identificadores C# válidos. No entanto, são identificadores .NET válidos evitando, assim, colisões de nomes entre o código gerado pelo compilador e o código escrito pelo programador.Para além de permitir reordenar a lista de argumentos, esta funcionalidade apresenta-se muito útil para documentar código que quando, por exemplo, a lista de argumentos é muito extensa ou é pouco claro o significado dos argumentos na declaração da chamada ao método.
- Agora os parâmetros pode ter valores por omissão:public void Method(int first, int second = 2, int third = 3)Os parâmetros com valores por omissão têm de ser os últimos da lista de parâmetros e esse valor é usado se o argumento correspondente estiver em falta na lista de argumentos da declaração da chamado ao método.Para esta declaração de chamada:int i = 0; Method(i, third: ++i); terá o seguinte código gerado pelo compilador:int i = 0; int CS$0$0000 = ++i; Method(i, 2, CS$0$0000);o que dará aos parâmetros do método os seguintes valores:first: 1 second: 2 third: 1
- Tal como mencionei na minha última entrada, expor publicamente métodos com argumentos opcionais é uma má prática (é por isso que o C# resitiu a tê-los, até agora).Podem argumentar que o vosso método ou construtor tem demasiadas variações e ter mais de dez variantes é um pesadelo de manutenção, e têm razão. Mas a solução já existe há muito tempo: classes de argumentos.O padrão da classe de argumentos é usado na .NET Framework por várias classes, com XmlReader e XmlWriter que usa este padrão nos seus métodos Create, desde a versão 2.0:XmlReaderSettings settings = new XmlReaderSettings();settings.ValidationType = ValidationType.Auto;XmlReader.Create("file.xml", settings);Com este padrão, não é necessário manter uma longa lista de sobreposições e quaisquer valores por omissão para propriedades de XmlReaderSettings (ou XmlWriterSettings para XmlWriter.Create) pode ser modificados ou até mesmo novas propriedades podem ser acrescentadas em futuras implementações sem que se quebre código já compilado existente.Podem agora argumentar que é demasiado código para escrever, mas, com os inicializadores de objectos introduzidos no C# 3.0, o mesmo código pode ser escrito assim:XmlReader.Create("file.xml", new XmlReaderSettings { ValidationType = ValidationType.Auto });Parece-se com argumentos com nome e opcionais, não parece? E, quem sabe, numa futura versão do C#, pode até parecer-se com isto:XmlReader.Create("file.xml", new { ValidationType = ValidationType.Auto });
- A principal funcionalidade do C# 4.0 é a programação dinâmica. Não apenas em termos de tipos dinâmicos, mas, un sentido mais lato, a capacidade de falar com qualquer coisa que não seja staicamente tipada para ser um objecto .NET.Dynamic Language RuntimeO Ambiente de Execução para Linguagens Dinâmicas (Dynamic Language Runtime - DLR) é um pedaço de tecnologia que unifica a programação dinâmica na plataforma .NET, da mesma forma que o Ambiente de Execução Comum para Linguagens (Common Language Runtime - CLR) tem sido a plataforma comum para linguagens estaticamente tipadas.A CLR sempre teve capacidedes dinâmicas. Sempre foi possível usar reflecção, mas o seu prinicpal objectivo nunca foi ser um ambiente de programação dinamido e faltava-lhe algumas funcionalidades. A DLR assenta na CLR e adiciona essas funcionalidades em falta à plataforma .NET.A DLR é a infra-estrutura base que consiste em:Dynamic DispatchAs mesmas árvores de expressões usedadas no LINQ, agora melhoradas para suportar instruções.Dynamic DispatchDespacha as invocações para o binder apropriado.Call Site CachingPara melhor eficiência.As linguagens dinâmicas e as linguagens dinâmicas assentam na DLR. O IronPython e o IronRuby já assentavam na DLR, e agora, o suporte para usar a DLR foi adicionado ao C# e ao Visual Basic. Espera-se que outras linguagens construídas sobre a CLR passem também, no futuro, a usar a DLR.Sob a DLR encontram-se os binders que falam com uma variedade de diferentes tecnologias:.NET BinderPermite falar com objectos .NET.JavaScript BinderPermite falar com JavaScript em SilverLight.IronPython BinderPermite falar com IronPython.IronRuby BinderPermite falar com IronRuby.COM BinderPermite falar com COM.Com todos estes binders é possível ter uma única experiência de programação para falar com todos estes ambientes que não são objectos .NET estaticamente tipados.
- Tomemos este tradicional código estaticamente tipado:Calculator calculator = GetCalculator(); int sum = calculator.Sum(10, 20); Porque a variável que recebe o valor de retorno do método GetCalulator é estaticamente tipada para ser do tipo Calculator e, porque o tipo Calculator tem um método Add que recebe dois inteiros e retorna um inteiro, é possível chamar esse método Sum e atribuír o seu valor de retorno a uma variável etaticamente tipada como inteiro.Agora suponhamos que a calculadora não era uma classe .NET estaticamente tipada, mas, em vez disso, um objecto COM ou algum códiogo .NET de que não conhecemos o tipo. De repente tornou-se muito penoso chamar o método Add:object calculator = GetCalculator(); Type calculatorType = calculator.GetType(); object res = calculatorType.InvokeMember("Add", BindingFlags.InvokeMethod, null, calculator, new object[] { 10, 20 }); int sum = Convert.ToInt32(res); E se a calculador for um objecto JavaScript?ScriptObject calculator = GetCalculator(); object res = calculator.Invoke("Add", 10, 20); int sum = Convert.ToInt32(res); Para cada domínio dinâmico temos uma experiência de programação diferente o que torna a unificação do código muito difícil.Com o C# 4.0 é agora possível escrever código como este:dynamic calculator = GetCalculator(); int sum = calculator.Add(10, 20); Basta declarar uma variável cujo tipo estático é dynamic. dynamic é uma pseudo palavra reservada (como var) que indica ao compilador que a resolução das operações sobre calculator será efectuada de forma dinâmica.Deve-se encarar um dynamic como um object (System.Object) com semântica dinâmica associada. Qualquer coisa pode ser afectada a dynamic.
- Em tempo de execução, todos os objectos terão um tipo. No exemplo acima, No exemplo precedente, em tempo de execução, x é do tipo System.Int32.Quando um ou mais operandos de uma operação são tipados dynamic, a selecção do método a chamar é deferida para tempo de execução ao invés de ser feita em tempo de compilação. Então o tipo em tempo de execução é substituído em todas as variáveis e a resolução de sobreposições (overloads) ocorre, tal como em tempo de com ocorreria em tempo de compilação.
- O resultado de qualquer operação dinâmtica é sempre dynamic e, quando um objecto dynamic é atribuído a algo, ocorre uma conversão dinâmica.double x = 1.75; double y = Math.Abs(x);Tempo de compilaçãodouble Abs(double x)dynamic x = 1.75; dynamic y = Math.Abs(x);Tempo de execuçãodouble Abs(double x)dynamic x = 2; dynamic y = Math.Abs(x);Tempo de execuçãoint Abs(int x)O código acima será sempre fortemente tipado. A diferença é que, no primeiro caso a resolução do método é feita m tempo de compilação, e nos outros em tempo de execução.
- A está DLR pré-preparada para conhecer objectos .NET, ojectos COM mas qualquer linguagem dinâmica pode implementar os seus próprios objectos dinãmicos, assim como qualquer programador pode implementar os seus objectos dinâmicos em C# através da implementação da interface IDynamicMetaObjectProvider. Quando um objecto implementa IDynamicMetaObjectProvider, pode participar na resolição de como os métodos são chamados ou as propriedaes acedidas.A .NET Framework já contem duas implementações de IDynamicMetaObjectProvider:DynamicObject : IDynamicMetaObjectProviderA classe DynamicObject permite definir que operações podem ser executadas em objectos dinâmicos e como serão executadas essas operações. Por exemplo, pode-se definir o que acontece quando se tenta ler ou escreve uma propriedade, chamar um método ou efectuar operações matemática como adições e multiplicações.ExpandoObject : IDynamicMetaObjectProviderA classe ExpandoObject permite adicionar e remover membros às suas instâncias em tempo de execução e também obter os valores desses membros. Esta classe suporta a ligação dinâmica que permite usar um sintaxe normal como sampleObject.sampleMember, em vez de uma sintaxe mais complexa como sampleObject.GetAttribute("sampleMember").
- A resolução dinâmica e argumentos com nome e opcionais melhoram largamente a experiência de interoperar com APIs COM como as Office Automation Primary Interop Assemblies (PIAs). Mas, para aliviar ainda mais o desenvolvimento de interoperabilidade com COM, foram adicionados algumas funcionalidades específicas para COM ao C# 4.0.
- Devido ao diferente modelo de programação, muitas APIs COM contêm muitos parâmetros por referência. A intenção deste parâmetros não é modificar os argumentos que lhes são passados, mas apenas outro modo de passar valores.Especificamente com métodos COM, o compilador permite declarar a chamada ao método passando os argumentos por valor e gerará automaticamente variávias temporárias para manter os valores por forma a poder passá-los por referência e descartará os seus valores após o retorno da chamad ao método. Do ponto de vista do porgramador, os argumentos são passados por valor.
- Importação DinâmicaMuitos métodos COM aceitam e retornam tipos variant, que são representados nas PIAs como object. Na grande maioria dos casos, o programador que está a chamar estes métodos conheço o tipo estático dos objectos que estão a ser retornados pelo contexto da chamada, mas ainda são obrigados a explicitamente converter o valor retornado para fazer uso desse seu conhecimento. Estas conversões são tão comuns que se tornam um incómodo.Para tornar a vida do programador mais fácil, é agora possível importar as APIs COM de modo a que os variants seja representados usando o tipo dynamic o que quer dizer que as assinaturas COM têm agora ocorrências de dynamic em vez de object.Isto quer dizer que membros de um objecto retornado podem agora ser facilemtne acedidos ou atribuídos a variáveis fortemente tipadas sem necessiade de conversão explícita.Propriedades Indexadas E Por OmissãoAlgumas funcionalidades das interfaces COM ainda não estão disponíveis em C#. No topo desta lista estão as propriedades indexadas e as propriedades por omissão. Como mencionado anteriormente, estas poderão ser usadas se a interface COM for acedida dinâmicamente, mas não serão reconhecidas por código C# estáticamente tipoado.
- Para assemblies indentificadas com PrimaryInteropAssemblyAttribute, o compilador criará tipos equivalentes (interfaces, estruturas, enumerados e delegates) e embebê-los-á na assembly gerada.Para reduzir a dimensão final da assembly gerada, apenas os tipos e seus membros usados serão gerados e embebidos.Embora isto torne o desenvolvimento e distribuição de aplicações que usam os componentes COM mais fácil porque não há necessidade de distribuír as PIAs, quem desenvolve os componentes COM continua a ter de desenvolver as PIAs.