Nos dois últimos artigos da série falei sobre dois tipos de variância que o C# suporta - covariância de array e covariância (nos tipos de retorno) e contravariância (nos tipos dos argumentos) na conversão de grupo de membros para delegate.

Hoje vamos generalizar este último tipo de variância.

Hoje no C# 3.0, embora seja válido atribuir um grupo de membros sem tipo para uma função que retorne uma Girafa para uma variável do tipo Func<Animal>, não é válido atribuir uma expressão tipada do tipo Func<Giraffe> para uma Func<Animal>. Tipos Generic do delegate são são sempre invariantes no C# 3.0. Isso parece fraco.

Suponha que nós temos a possibilidade de declarar os tipos dos parâmetros dos tipos generic do delegate como sendo covariante ou contravariante. Para simplificar (e manter a consistência com a notação existente nas especificações da CLR) iremos escrever os parâmetros de tipo covariante com um + e os parâmetros de tipo contravariantes com um -.

Esta não é uma notação muito atraente. Mas por enquanto vamos usá-la. A forma de se lembrar o que o + significa é "este tipo aceita tipos maiores na atribuição", e menores para o -.

Considere, por exemplo a nossa função padrão:

delegate R Func<A, R>(A a);

Desde que R apareça somente no retorno e A apareça somente na lista de parâmetros, podemos fazer do R covariante e o A contravariante:

delegate R Func< -A, +R >(A a);

Então novamente, você pode pensar nisto como "você pode fazer o A menor ou o R maior" (ou, é claro, ambos). Por exemplo:

Func<Animal, Giraffe> f1 = qualquer;

Func<Mammal, Mammal> f2 = f1;

Normalmente no C# esta atribuição será inválida porque os delegates são parametrizados por tipos diferentes. Mas desde que nós temos Func variante em ambos tipos de parâmetros, esta atribuição deveria se tornar válida para adicionar este tipo de variância à uma futura versão do C#.

Será que isto faz sentido até agora?

Esta regra nem sempre é correta! Algumas vezes o parâmetros de entrada precisa ser de um tipo de parâmetro covariante (no nosso exemplo A é contravariante). Iremos discutir isto somente no próximo artigo.

Na primeira parte vimos que os métodos static não sempre determinados em tempo de compilação, e usamos este fato para justificar o porque dos métodos static não poderem ser chamados em tipos passados por parâmetro. Mas os argumentos de tipos das Generics não são determinados em tempo de compilação?

No lado de quem os chama, sim. Mas para quem é chamado, o código enviado em tempo de compilação para um método genérico é inteiramente genérico. E assim continuará até que o jitter encontre o código em tempo de execução e faça a substituição dos tipos por argumento pelos tipos passados por parâmetros.

Considere a seguinte Generic:

public class C<T> { public string M() { return typeof(T).ToString(); } }

Quando você a compila, o compilador enviará uma definição de classe genérica que diz apenas que nós temos uma classe, que tem um tipo por parâmetro, e um método que chama o ToString(). Este é todo o código que é enviado para esta classe em tempo de compilação.

Para deixar mais claro, quando você diz:

void N() { C<int> c = new C<int>(); string s = c.M(); //...

O compilador não cria uma cópia da classe no código IL com o T substituído por int.

Em vez disso, o que acontece é que quando seu método N é jittado, o jitter diz, Hey, Eu preciso traduzir C<int>.M. Neste ponto o jitter consome o IL genérico emitido pelo C<T>.M e cria um novo código x86 (ou o que for) com int substituindo T.

Diferentemente dos templates no C++ que não definem tipos genéricos. Em vez disso, templates C++ são basicamente um atalho em tempo de compilação, como um complexo buscar-e-substituir. Se você dizer C<int> no C++, então em tempo de compilação, o compilador C++ textualmente irá substituir int pelo T e enviar o código como se você tivesse escrito a classe usando o int.

Se o C# tivesse templates em vez de macros então um método static chamado em um template realmente seria determinado em tempo de compilação, porque a classe inteira seria processada em tempo de compilação. Este sentido de templates é um mecanismo mais poderoso que generics – você pode fazer coisas loucas com templates porque eles não são "type safety" imposto sobre o modelo como um todo. Pelo contrário, o "type safety" só está marcado para cada construção do template efetivamente no programa.

Mas tipos genéricos no C# não são templates, eles devem ser "typesafe" dada qualquer possível construção a qual satisfaça as regras, não somente sobre um conjunto que está atualmente construído em um programa em particular.

A Microsoft anunciou um novo sistema operacional nesta terça-feira: o Singularity. Mas não se empolgue muito: ele é um "carro-conceito em forma de SO", disse Rick Rashid, diretor geral do Microsoft Research.

A Microsoft está disponibilizando o protótipo desse sistema operacional gratuitamente para comunidades acadêmicas e pesquisadores na esperança de que eles o usarão para desenvolver novos tipos de arquiteturas para computadores.

É difícil para a comunidade acadêmica fazer experiências com arquiteturas de computadores, disse ele. O Singularity foi criado para tornar fácil para os pesquisadores testarem como sistemas operacionais e aplicações podem interagir entre si.

"É um novo sistema criado do zero, com o objetivo específico de ser mais confiável", disse Rashid. O Singularity foi desenvolvido em C# e a Microsoft espera que ele ajude a melhorar a confiabilidade do software e acelerar as pesquisas com linguagens de programação e ferramentas.

O Singularity está disponível no site Microsoft CodePlex. Ele foi apresentado nesta terça-feira durante a TechFest, evento anual onde a Microsoft exibe projetos da sua divisão de pesquisas.

Mais: Projeto Singularity

Está disponível a edição de Março da MSDN Magazine, este mês especialmente chamada de Launch 2008, devido aos lançamentos que teremos este mês, Windows Server 2008, SQL Server 2008 e do Visual Studio 2008. Engraçado que nenhum deles será realmente lançado este mês...

O Visual Studio 2008 está disponível em versão final desde Novembro de 2007, o Windows Server 2008 desde Fevereiro de 2008 e o SQL Server sofreu um atraso e chega só no final do ano.

Assuntos de capa:

• WCF móvel: Escreva um aplicativo IM com o .NET Compact Framework.
  O .NET Compact Framework 3.5 fornece um subconjunto da funcionalidade do Windows Communication Foundation (WCF) que você pode utilizar para se comunicar entre os dispositivos Windows Mobile e computadores desktop. Mostraremos a você como fazer isso. Andrew Arnott



• IIS 7.0: Construa soluções de servidor Web com extensibilidade ponta a ponta
  Mike Volodarsky demonstra o modelo de extensibilidade do IIS 7.0 ao estender a Modificação de resposta a um módulo de servidor Web configurável e uma página de gerenciamento personalizado para o Gerenciador do IIS. Mike Volodarsky



• VSTO 3.0: Desenvolvendo aplicativos comerciais de escritório com o Visual Studio 2008. Com as regiões de formulário personalizadas no Outlook, você pode receber dados de fontes de dados designadas e personalizar verdadeiramente a experiência do Outlook 2007 dos seus usuários. Steve Fox



• Teste de unidade: Aplique o desenvolvimento controlado por testes aos projetos de banco de dados.
  Jamie Laflen exalta as vantagens do TDD quando aplicado ao desenvolvimento de banco de dados – e também fornece algumas técnicas úteis. Jamie Laflen



• F# Primer: Uso de técnicas de programação funcionais no .NET Framework
  Vamos apresentar aqui alguns dos conceitos por trás da nova linguagem F#, que combina elementos de linguagens .NET funcionais e orientadas a objeto. Em seguida, ajudaremos você a começar a escrever alguns programas simples. Ted Neward

Download - Download dos Códigos

Considere o seguinte:

public class C { public static void M() { /*blablabla*/ } }
public class D : C { public new static void M() { /*blablabla*/ } }
public class E<T> where T : C { public static void N() { T.M(); } }

Isso é ilegal. Nós não podemos chamar um método static sob um tipo variável. A questão é, por quê? Nós sabemos que T deve ser um C, e C tem um método static M, então por que isto não é válido?

Espero que você concorde que uma das seguintes afirmações deve ser verdadeira:

1) Isto é inválido.
2) E<T>.N() chama C.M() não importa o que T é.
3) E<C>.N() chama C.M() mas E<D>.N() chama D.M().

Se nós pegarmos a opção 2, então isto é tão sem sentido quanto totalmente inútil. O usuário irá esperar que D.M() seja chamado se T for um D. Porque senão para que teriamos o trabalho de chamar T.M() em vez de C.M() se ele irá "sempre chamar C.M()"?

Se pegarmos a opção 3, então nós temos uma violação dos princípios de design do núcleo dos métodos static, o princípio que lhes deu o nome. Métodos estáticos são chamados “static” porque eles podem sempre determinar exatamente, em tempo de compilação, qual método será chamado. Ou seja, o método pode ser resolvido unicamente por análise estática do código.

Só sobra a opção 1.

Perguntas relacionadas são frequentemente abordadas, de várias formas. Muitas pessoas costumam perguntar porque C# não suporta métodos “virtual static”. Mas o que elas estão querendo dizer? Pois “virtual” e “static” são opostos! “virtual” significa“determinar o método a ser chamado baseado nas informações de tipo em tempo de execução”, e “static” significa“determinar o método a ser chamado unicamente baseado na análise estática em tempo de compilação”.

Na verdade o que as pessoas querem é um outro tipo de método, que não seja static, instanciado ou virtual. Nós poderiamos chegar à uma nova espécie de método que se comporta como a opção 3. Isto é, um método associado com o tipo (como um static), que não tem um argumento this "non-nullable" (diferente de um instanciado ou virtual), mas um onde o método chamado deve depender do tipo construído sobre o T (diferente de um static, o qual deve ser determinado em tempo de compilação).