Covariância e Contravariância em C#, Parte Cinco: Contravariância Dupla

04/25/2008 08:14:00 By Felipe Pessoto

Na parte quatro da série, falamos sobre como poderiamos ter um tipo de delegate que aceitaria ter valores covariantes no seu tipo de retorno e contravariantes no tipo recebido por argumento. Por exemplo, nós podemos ter um delegate action contravariante:

delegate void Action< -A > (A a);

e então temos

Action<Animal> action1 = (Animal a)=>{ Console.WriteLine(a.NomeLatin); };
Action<Girafa> action2 = action1;

Porque o invocador do action2 irá sempre passar algo que o action1 possa manipular.

Baseado no que vimos até agora no que diz respeito à variância concluimos que "o que está entrando deve ser contravariante, o que sai deve ser variante". Embora pareça que este seria um uso comum de variância que deveria ser implementada numa futura versão do C#, a realidade é um pouco mais complicada. Há uma situação onde é válido usar um argumento covariante como parâmetro de um delegate.

Suponha que você queira criar uma programação funcional de "ordem maior". Por exemplo, talvez você queira definir uma meta-ação – um delegate que recebe actions e faz alguma coisa com eles:

delegate void Meta<A>(Action<A> action);

Por exemplo:

Meta<Mamifero> meta1 = (Action<Mamifero> action)=>{action(new Girafa());};

// A próxima linha é válida porque Action<Animal> é menor que Action<Mamifero>;
// lembrando que Action é contravariante
meta1(action1); 

Então este Meta recebe um Action de Mamiferos, ou o action1 acima, o qual exibe o nome em Latin de qualquer Animal, o que quer dizer que pode ser usado para os Mamifero – e então invoca aquela action usando o new Girafa.

É evidente que o parâmetro de tipo A é usado em uma posição de entrada na definição de Meta<A>, então nós devemos ser capazes de usar contravariancia, certo? Suponha que sim. Isso significa que essa atribuição seria válida:

Meta<Tigre> meta2 = meta1; // deve ser válida se Meta é contraviante no parâmetro

Mas isso significa que isso seria válido:

Action<Tigre> action3 = Tigre=>{ Tigre.Rosnar(); };
meta2(action3);

Seguindo a lógica você verá que no final acabamos chamando (new Girafa()).Rosnar(), o qual claramente viola ambas as regras: do sistema e da natureza. Pode ser um pouco complicado até entender toda a lógica, mas escrevendo o código pode ajudar:

static void Main(string[] args)
        {
            Action<int> a;
 
            Action<Animal> action1 = metodo;
            Action<Girafa> action2 = action1;
 
            Meta<Mamifero> meta1 = metodo2;
 
            meta1(action1);
 
 
            Meta<Tigre> meta2 = meta1;
            Action<Tigre> action3 = metodo3;
            meta2(action3);
 
            Meta<Animal> meta3 = meta1;
 
 
        }
 
        static void metodo3(Tigre Tigre)
        {
            Tigre.Rosnar();
        }
 
        static void metodo2(Action<Mamifero> action)
        {
            action(new Girafa());
        }
 
        static void metodo(Animal a)
        {
            Console.WriteLine(a.NomeLatin);
        }
 
        public delegate void Meta<A>(Action<A> action);

No final do Main, você pode ver que o meta2 é igual ao meta1. O meta1 chama o método 2. O método 2 vai chamar o action passado(no caso o action3 que chama o metodo3) passando um new Girafa() como parâmetro. Neste momento que acontece a inconsistência. Pois estamos chamando o método3 passando uma Girafa, e o método3 iria chamar o método new Girafa()).Rosnar().

Então Meta<A> não pode ser contravariante em A. No entanto ele pode ser covariante:

Meta<Animal> meta3 = meta1; // válido se Meta for covariante

Agora tudo funciona. meta3 recebe um Action sobre Animals e então passa um Girafa para a Action.

Contravariância é complicado. O fato de se inverter o maior/menor relacionamento entre tipos diz que um tipo de parâmetro usado em uma posição de "contravariância dupla" (sendo uma entrada de Action, que é em si uma entrada de Meta) se torna covariante. O segundo desfaz a primeira inversão.

No próximo artigo deixaremos os delegates pra trás e falaremos sobre variância nas interfaces.

Chamar métodos static por tipo variável é ilegal - Parte III

04/17/2008 09:12:00 By Felipe Pessoto

Considere agora o método não-static e não-virtual:

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

Nesse contexto, uma das seguintes afirmações é 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.

Como temos discutido, para métodos static escolhemos a opção 1. Mas com métodos por instância, nós escolhemos a 2! A maioria das pessoas acharia que o método mais derivado(opção 3) seria chamado, mas não. Por quê? Porque temos que considerar que poderíamos ter: public static void N(C t) { t.M(); } o que nos faz esperar que o método menos derivado seja sempre chamado, desde que ele não seja virtual.

Por que não a opção 3? Novamente, tem a ver com análise estática. É que na realidade o que temos em ambos os casos, static e instanciados, C.M e D.M são métodos diferentes. O "new" solicita que eles sejam dois métodos diferentes que somente compartilham o mesmo nome. Você pode pensar em cada método como se ele ocupasse uma "vaga" no objeto, tanto em static como instanciado, nós definimos duas vagas, não uma. No caso do virtual e override então nós teríamos apenas uma vaga, e o conteúdo da vaga seria determinado em tempo de execução. Mas no caso não-virtual há duas vagas diferentes.

Quando o compilador gera o código generic, ele "calcula" todas as vagas em tempo de compilação. O jitter não as altera. Na verdade, o jitter não saberia como! O jitter não tem idéia que D.M tem qualquer coisa a ver com C.M. Novamente, eles são métodos totalmente diferentes que somente coincidentemente compartilham o mesmo nome. Eles têm vagas diferentes então são métodos diferentes.

Disponível ASP.NET Dynamic Data Preview

04/10/2008 08:07:00 By Felipe Pessoto

A meses atrás foi liberado um Preview do ASP.NET 3.5 Extensions que continha novas funcionalidades que estão por vir este ano (incluindo melhorias no ASP.NET AJAX, ASP.NET MVC, Suporte ao ASP.NET Silverlight e ASP.NET Dynamic Data).

O ASP.NET Dynamic Data adicionou várias novas funcionalidades que permitem que você construa rapidamente uma página de acesso a dados que funcionam com LINQ to SQL ou LINQ to Entities. ASP.NET Dynamic Data permite que você automaticamente tenha uma página totalmente funcional de entrada de dados e relatórios que são dinamicamente construídas a partir dos meta-dados do seu modelo ORM. Além disso, você pode opcionalmente sobrescrever e customizar qualquer um dos templates usando HTML ou o código que você quiser, dando um controle total ao desenvolvedor.

ASP.NET Dynamic Data Preview

Hoje foi liberado uma atualização do ASP.NET Dynamic Data Preview. Para saber mais e fazer o download clique aqui.

Este novo dynamic data preview agora funciona com os controles de dados padrão do ASP.NET (GridView, ListView, FormView, DetailsView, etc). O suporte ao Dynamic Data permite que esses controles possam manipular automaticamente relacionamentos com chave-estrangeira. Por exemplo, um gridview irá automaticamente mostrar o nome do registro na coluna de chave estrangeira em vez do código dela:

 

O novo dynamic data também suporta validações automáticas (tanto no lado cliente quanto no servidor) levando em consideração as constraints que você tem no seu modelo de dados. Por exemplo, se uma coluna no banco de dados é limitada em 50 caracteres, e está marcada como non-nullable, controles de validação apropriados serão aplicados à página para garantir que essas regras serão seguidas. Se você mudar as constraints dentro das suas classes LINQ to SQL ou LINQ to Entities, a interface gráfica irá automaticamente fazer essas mudanças na próxima vez que for chamada, para garantir que as novas constraints serão obedecidas.

Todas as funcionalidades acima estarão presentes para o LINQ to SQL e LINQ to Entities.


Visual Studio Dynamic Data Project Wizard

Outra novidade foi adicionada ao ASP.NET Dynamic Data, o "Time de Ferramentas Web do VS" também terminou um primeiro preview de um novo assistente para projetos usando dynamic data que permite criar rapidamente um site para manipular dados. O assistente permite que você selecione um banco de dados, e então as tabelas, views e sprocs que você deseja construir no seu modelo LINQ to SQL:



Depois de criar um modelo de dados, o assistente deixa você escolher facilmente o template das páginas para manipular os dados:



Você pode então escolher qual tipo de interface é suportada em cada página:

Covariância e Contravariância em C#, Parte Quatro: Variância de Delegate Real

04/01/2008 10:49:00 By Felipe Pessoto

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.