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.

Permalink | Comments (0)

Tags: Covariância e Contravariância

Categories: Artigos

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.

Permalink | Comments (0)

Tags: métodos static

Categories: Artigos

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.

Permalink | Comments (0)

Tags: Covariância e Contravariância

Categories: Artigos

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.

Permalink | Comments (0)

Tags: métodos static

Categories: Artigos

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).

Permalink | Comments (0)

Tags: métodos static

Categories: Artigos