Uma type class para os acostumados com OO pode ser vista como uma interface cuja implementações são externas aos tipos que estão atrelados. Um exemplo bem simples é Eq, que permite compar objetos do mesmo tipo:

class Eq a where
    (==), (/=) :: a -> a -> Bool
    x /= y = not (x == y)
    x == y = not (x /= y)

Para nos não iniciado em Haskell, linha um define a classe Eq e diz que ela possui um parâmetro polimófico; linha 2 diz que Eq tem 2 funções, “==” e “/=” cuja assinatura são dois valores do tipo ‘a’ e retorna um booleano; por fim, linhas 3 e 4 são implementações padrão das funções. Seria o equivalente, em pseudo-C#, ao seguinte:

interface Eq<T> {
   bool operator== (T a, T b) { return !(a != b); }
   bool operator!= (T a, T b) { return !(a == b); }
}

Uma das vantagens de type classes no Haskell é que elas podem fornecer implementações padrão para alguns de seus métodos. Bom, agora que temos Eq definida, para dizer que Listas a implementa usamos algo como:

instance Eq a => Eq [a] where
    [] == [] = True
    (x:xs) == (y:ys) = x==y && xs==ys
    _ == _ = False

Aqui vemos uma das melhores características do Haskell é explorada, que é pattern matching – e isso também é assunto para outro artigo. Como pode se notar, uma implementação de uma dada type class não está embutida na definição do tipo em questão, ou seja, não podemos interfaces como a CLR ou a JVM suportam.

A idéia é representar type classes de forma semelhante a como o ghc faz, usando dictionary passing[1], que é bem simples de entender e implementar. Para cada type class que uma função recebe nos seus parâmetros, passamos junto um objeto que representa as operações em questão. Em C# teríamos:

interface Eq<T> {
    bool op_eq (T a, T b);
    bool op_neq (T a, T b);
}
 
class Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_eq (int a, int b) { return a != b; }
}
 
int Fun<T> (Eq<T> dict, T a, T b) {
    if (dict.op_eq (a, b))
        return 1;
    return 0;
}

Existe alguns problemas aqui, primeiro que estamos passando um parâmetro extra e segundo que não é possível eliminar a verificar por null pointer caso op_eq seja inlined. A solução é razoavelmente simples no caso do C#:

struct Eq_Int : Eq<int> {
    public bool op_eq (int a, int b) { return a == b; }
    public bool op_neq (int a, int b) { return a != b; }
}
 
int Fun<T, TD> (T a, T b) where TD: Eq<T> {
    if (default (TD).op_eq (a, b))
        return 1;
    return 0;
}

A grande mudança aqui é tornar a instância da typeclass um valuetype e construir um valor default para satisfazer o compilador. É uma pena que não podemos simplesmente chamar um método estático e TD, o que é uma limitação boba da CLR. Essa solução não é possível na JVM devido a inexistência de valuetypes e generics.

E quanto a performance dessa solução? Bom, no caso do mono, o JIT’er reconhece as chamadas como não virtuais e é capaz de fazer inline de forma bem agressiva – exatamente como desejado. Eu pensei em fazer um comparativo dessa solução com o equivalente em Java, mostrando como a CLR permite codificar tipos muito mais ricos e interessantes que a JVM – e como isso se traduz em performance. Mas realmente não estou afim de criar motivo para um flamewar por parte dos javeiros de plantão.

[1]Esse é o paper original que descreve type classes e a técnica utilizada: http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

Hoje a maioria ainda está no estágio de possuir um interpretador razoável e estar começando a investir em algum mecanismo primitivo de compilação para código nativo. Talvez a única diferença seja o uso de inline caches para resolução de nomes, que foi uma contribuição significativa do pessoal do Self no começo dos anos 90. Porém os principais resultados obtivos por pesquisas a um bom tempo, como tracing, especialização e especulação não deram as caras ainda.

Inline caching é uma optimização no qual o resultado da resolução de nomes, para dispatch de método por exemplo, é armazenado entre ativações distintas. O truque é introduzir uma clausula de guarda que verifica o tipo do objeto seletor e sua versão. Caches devem ser invalidados sempre que alguém alterar uma classe. Temos dois tipos de cache, os monomórficos que fazem caching de apenas uma invocação e os polimórficos, que armazenam uma série de resultados. Para melhor vamos exemplificar com pseudo código:


//ruby
def test (a)
a.foo
end

//pseudo-código do delegate depois de chamarmos test ("str")
object test_site_0_v2 (object _this) {
if (_this.Type == typeof (int) && _this.version == 1)
return ((int)_this).foo ();
if (_this.Type == typeof (string) && _this.version == 1)
return ((string)_this).foo ();
return ResolveAndInvoke (a, "foo", ref test_site_0);
}


Como fica claro pelo exemplo, um cache polimórfico tem uma performance superior pois usa literais e funciona muito melhor no caso de não existir um tipo dominante entre as ativações. Aqui fica clara a limitação de uma das implementações, o JRuby não pode se dar ao luxo de gerar tantos métodos pois cada um precisa de uma classe e um classloader novos, ou seja, abusa da PermGen do Java.

Apesar de inline caches resultarem em ganho expressivo de performance, estão longe de produzirem algo razoável. O grande problema continua sendo o enorme custo de dispatch para código simples. A chave disso é fazer inferência dos tipos, de forma a conseguir eliminar por completo o overhead dos caches e resolução de nomes. As atuais implementações não implementam se quer inferência estática, ou seja, código como “123.to_s” é executado sem qualquer conhecimento prévio de 123.

O grande avanço ocorre se fizemos inferência em tempo de execução. Ou seja, instrumentamos o código para coletar os tipos que aparecem pelo código durante a execução e baseado nisso a máquina virtual gera versões mais eficientes do código. Existem duas técnicas bastante difundidas de como fazer isso, uma é via especialização parcial de métodos e a outra é via trace-based optimization.

Trace-based optimization é a tecnologia adotada pela Tamarin, a próxima VM de Javascript da Mozilla. De maneira sucinta, essa técnica consiste em gravar os trechos, e os tipos encontrados, que executam mais freqüentemente e gerar código eficiente baseado nessa informação. Os trechos gravados costumam incluir vários métodos diferentes e suas ativações juntas. Suas principais vantagens é a conseguir fazer inlining de métodos de maneira muito eficiente e normalmente gastar menos tempo no JIT. Porém existem uma enorme quantidade de problemas complexos de serem resolvidos como limitar expansão descontrolada da quantidade de código gerado.

Especialização parcial de métodos também leva em conta os métodos que executam mais freqüentemente. Os tipos dos parâmetros e valores de retorno
são armazenados e posteriormente utilizados para gerar versões especializadas dos métodos em questão. Sua principal vantagem é a maior simplicidade
e o fato de existir muito mais literatura e ferramentas para gerar código eficiente nestes casos. Para se ter uma idéia do poder dessa técnica um exemplo cai bem:


//ruby
def fun (a, b)
2 * a - b
end

object fun_v1 (object a, object b) {
if (a.Type == typeof (int) && b.Type == typeof (int) && typeof (int).version == 1)
return fun_int_int ((int)a, (int)b);
object tmp = Invoke (2, "*", a"); //_this, nome do método, argumentos
return Invoke (tmp, "-", b);
}


Não precisa ir muito longe para imaginar a diferença de performance entre as duas versões. Porém entre descobrir os métodos as serem especializados e gerar código de máquina existe um Just-In-Time compiler que é, surpresa, surpresa, muito trabalhoso de ser escrito para executar rapidamente e gerar código eficiente.

Possui um bom JIT é atualmente um grande dilema entre as implementações de ruby. Pois ao usar o JIT de máquinas virtuais maduras, como HotSpot ou mono, a implementação fica limitada ao que é possível a linguagens gerenciadas. Em contrapartida, ao não utilizá-las, construções de baixo nível como profiler e interpretador podem ser implementadas de forma muito mais eficiente.

Apesar de do futuro parecer muito legal, futuras VMs terão o trabalho adicional de educar a comunidade de desenvolvedores sobre como escrever código rápido em ruby. Coisas como monkey patching furam qualquer esquema de caching ou especialização pois cada objeto passa a ter uma singleton class distinta.

Não existe solução fácil e todas implementações tem muito chão pela frente até Ruby ter uma performance competitiva com outras linguagens dinâmicas. Soluções como as aqui apresentadas devem conseguir melhorias de uma ordem de magnitude tranquilamente, de acordo com os resultados já encontrados. Performance é um problema que é resolvido via muito suor, com uma contínua série de melhoras, atacando um pouco por vez.

Sistemas grandes e complexos exigem que seus componentes sejam isolados o máximo possível entre si para minimizar a interferência que um pode causar no outro. Em linguagens como Java, com um sistema de tipos simples, normalmente isso se resume a usar interfaces para delimitar fronteiras e protocolos de comunicação inter-módulo. Porém quando temos classes abertas o problema é muito maior, já que o sistema todo pode ser modificado de um único lugar. Permitir que a modificação de classes fundamentais como Kernel em um canto do sistema influencie todo o resto é um sério problema pois fica difícil controlar o estrago que essas mudanças causam.

O problema com Ruby pode ser entendido melhor se olharmos para ele segundo o a classificação de domínios de page-jones. Segundo o mesmo, podemos classificá-los em fundamental, arquitetural, negócios e aplicação; sendo que a especificidade aumenta na mesma ordem. Outro ponto é que o domínio menos específico não deve depender de um mais específico, assim como dependências laterais devem ser evitadas. Por essa ótica, código da aplicação alterando uma classe fundamental do sistema é uma clara violação desse modelo.

O motivo pelo qual Ruby viola o modelo de page-jones é por não ser possível definir um escopo que não seja global para alterações feitas a classes externas a código em questão. Outro problema que agrava a situação é a impossibilidade de realmente controlar o mecanismo de resolução de nomes de um bloco de código, isso é um grande problema para criação de DSLs que acabam por fazer enormes cirurgias no core da linguagem ou apelam para o monkeypatching, uma “solução” muito menos intrusiva.

Existem duas formas de ser realizar meta-programação; uma é a intrínseca, a qual se permite operar sobre a definição dos tipos e, uma vez feita a alteração, ela é visível a todos usuários do dado tipo, podemos dizer também que é meta-programação no ponto de definição; a outra é a extrínseca, na qual se altera o mecanismo de resolução de nomes para um dado corpo de código, isso permite realizar as mesmas operações que o método anterior, porém todo código precisa informar direta ou indiretamente se existe algo alterando tal mecanismo, podemos dizer também que é meta-programação no ponto de uso.

A vantagem do primeiro é simplicidade e alcance, uma vez feita a modificação nada mais precisa ser feito para sua aplicação utilizar a versão modificada do tipo, porém também é sua fraqueza, pois se uma função depender explicitamente do comportamento anterior ela não mais funcionará – Ruby é um ótimo exemplo de meta-programação intrínseca. Já a segunda técnica é quase o oposto, pois exige que as modificações sejam explicitamente ativadas, que é sua principal vantagem, pois permite facilmente compor conjuntos de alterações e restringir seu escopo, em contrapartida é sua fraqueza pois não permite que uma dada alteração seja definida por completo em um único lugar – extension methods do C# 3.0 é um exemplo simples de meta-programação extrínseca.

Tentar comparar ambas as técnicas e concluir qual a melhor é um exercício fútil, pois sempre existirão fartos casos no qual uma falha e a outra brilha. Assim como achar que Ruby é uma linguagem quebrada por possuir seus defeitos, pois apesar de tudo é um modelo ao mesmo tempo muito rico e simples de usar.

Em Java:

int soma_array (int[] array) {
    int r = 0;
    for(int i = 0; i < array.length; ++i)
        r += array[i];
    return r;
}

Em Erlang:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista([H | T], Acc) ->
    soma_lista(T, H + Acc);
 
soma_lista([], Acc) ->
    Acc.

Nada de especial na versão em Java, já a versão em Erlang é bem enigmática, para a maioria quase indecifrável. O problema, talvez, seja o fato de ser uma linguagem puramente funcional, que significa, entre outras coisas, que não existe destructive assignment – não é possível alterar o valor de qualquer coisa depois de definida. Por isso que todo loop deve ser escrito usando tail recursion*.

Há quem possa achar que a sintaxe não ajuda, pois estamos usando notação própria para pattern matching e processamento de listas. Porém, como veremos, é possível reescrevê-lo removendo a sintaxe enxuta por algo mais familiar a linguagens imperativas. Para exemplificar esse processo, vou aproximar a versão Java o máximo da em Erlang e o primeiro passo é introduzir recursão.

int soma_array(int[] array) {
    return soma_array (array, 0, 0);
}
 
int soma_array(int[] array, int idx, int acc) {
    if (idx == array.length)
        return acc;
    return soma_array(array, idx + 1, acc + array[idx]);
}

Bem melhor agora! O código lembra um pouco mais a versão funcional. Porém ainda tem a diferença que Erlang usa listas encadeadas no lugar de arrays e são processadas maneira similar ao LISP, utilizando uma função que retorna o primeiro elemento e outra que retorna o resto da lista depois do primeiro. Se modificarmos o código Java para levar isso em conta, vamos ter algo que lembra muito Erlang. O código fica da seguinte forma:

interface Lista {
    int head();
    List tail();
    boolean isEmpty();
}
 
int soma_lista(Lista list) {
    return soma_array (list, 0);
}
 
int soma_lista(List list, int acc) {
    if (list.isEmpty())
        return acc;
    return soma_lista (list.tail(), acc + list.head());
}

Agora que temos uma versão do código Java com o devido processamento de listas, que tal reescrever a versão em Erlang para não usar a notação de processamento de listas e pattern matching. Com isso teremos algo que é gritantemente próximo ao exemplo anterior, como veremos a seguir:

soma_lista(Lista) ->
    soma_lista(Lista, 0).
 
soma_lista(Lista, Acc) ->
    if
        Lista == [] -> Acc;
        true -> soma_lista(tl(Lista), Acc + hd(Lista))
    end.

Agora sim, temos aquilo que meu amigo pode chamar de código decifrável. Porém não é sem abrir mão do poder da linguagem – o que é uma pena, eu diria. Um programador de Erlang provavelmente iria estranhar ver algo como escrito na última versão. Para terminar esse artigo vou mostrar como ficaria se utilizarmos as funções de acesso aleatorio a listas, algo não muito aconselhável, já que é uma operação O(N).

soma_lista(Lista) ->
    soma_lista(Lista, 1, 0).
 
soma_lista(Lista, Idx, Acc) ->
    if
        Idx > length(Lista) -> Acc;
        true -> soma_lista(Lista, Idx + 1, Acc + lists:nth(Idx, List))
    end.

*Já me descobri péssimo com tradução, por isso não me arriscarei com essa também.

Ponteiros exigem que a pessoa desenvolva a disciplina mais complicada a um programador, que entender e explorar indireção. Todo problema difícil pode ser resolvido facilmente quando adicionamos um nível extra de indireção, está é uma das máximas da nossa área, que é importante para todo profissional. O complicado é conseguir ver uma pessoa assimilando a idéia de comportamento indireto, ainda mais por ser algo sem exemplos na natureza.

Quando falamos de pattern matching, o segredo por trás é a decomposição estrutural, pela qual os casamentos são realizados. Erlang e Scala são exemplos de linguagens que suportam esse recurso. Sua principal utilidade está em expressar uma série de condicionais de maneira muito mais simples e clara que usando operadores tradicionais. O porém fica pelo fato de sua operação ser muito mais interessante quando usamos tipos algébricos (assunto para outro artigo) que para objetos, então não é nada simples integrar com um linguagem OO.

A utilidade em aprender ambos vai além de saber como usá-las, está em entender o fundamento por traz de cada um pois muitos dos grandes avanços da programação estão enraizados neles – reparem como a maioria do catalogo do GoF trata apenas do uso de indireção adicional.

Curiosamente volume de dados nunca foi a razão pelo qual o prevayler não tinha razão. Uma delas foi latência e tempo médio de resposta, mas como pode isso ocorrer se o prevayler é tão super mais rápido nas consultas? Simples, o enorme uso de heap tornava o tempo de garbage collection proibitivo, um SGBD usa memória de maneira muito mas eficiente sob o viés do tempo para dar manutenção nela, esse sistema terminou com uma JVM usando 64Mb e a base toda dentro do cache do banco de dados. Outro problema foi confiabilidade, o log do prevayler não é protegido de partial writes e usa statement based logging, que não permite recuperação parcial, então se tua controladora corromper o meio do teu log, você se lascou. Porém o maior problema do prevayler é o desenvolvimento com equipes distribuídas ou de médio porte em uma estrutura matricial de projetos, isto é, o esforço de coordenar schema evolution é massacrante, não existe como compartilhar facilmente uma base de dados e a integração entre projetos é infernal.

Quanto ao fato de Java ser uma péssima escolha, primeiro pelo fato de não ser uma linguagem baseada em imagem, como smalltalk ou factor, na qual salvar a imagem da heap toda é tão difícil quanto chamar um único método, você não tem que se preocupar com criar toneladas de Commands e transações com rollback são possíveis de ser criadas usando STM(Software Transactional Memory) ou simplesmente alguns become(). Outro problema é que criar buscas complexas com Java é um desastre, muito difícil de bater álgebra relacional ou simplesmente SQL nisso, nesse ponto linguagens funcionais dão um show no Java que beira a humilhação, aplicar predicados e transformações sobre coleções, criando e processando tuplas é super simples, é arroz-com-feijão.

No geral, eu vejo o prevayler com um brinquedo educacional para se aprender sobre serialização e só, usar profissionalmente não é interessante do aspecto que vai significar muito provavelmente trabalhar em projetos desintessantes ou mentalmente castrantes. Klaus e companhia que me desculpem, mas esse tipo de problema eu passo adiante, prefiro ficar com os mais divertidos e interessantes.

A regra de escopo que torna classloading um enorme inferno, principalmente pela sutileza que acontece e te morde. De acordo com o Daniel, o classloader acionado não é necessariamente aquele que resolve o tipo, isso acontece devido a delegação. O mecanismo de delegação funciona muito bem quando somente um classloader da hierarquia é capaz de carregar uma dada classe e não existe dependências entre classes no sentido inverso da hierarquia existente entre eles.

Explicando melhor esses dois pontos; primeiro, somente um classloader da hierarquia deve ser capaz de carregar uma dada classe, isso se faz necessário senão acabamos com problemas de esquizofrenia de tipos, quando uma classe é carregada por dois classloaders e passa a existir como dois tipos distintos e gera vários ClassCastException sem razão aparente.

Por exemplo, dado o código a seguir e a existência de dois classloaders: João e José. Imaginemos a situação na qual a tanto José quanto João carregam a classe Exemplo, cada um definindo um tipo. Vamos supor agora que a aplicação chame novaCoisa de uma instância de Exemplo criada a partir do tipo definido pelo classloader João e passe como parâmetro de uma chamada a fazCoisa de uma instância vinda de José. Por mais curioso que seja, o resultado vai ser um ClassCastException e “nome da classe: Exemplo” escrito no console. Legal, não?


class Exemplo{
public void fazCoisa(Object obj) {
System.out.println("nome da classe: "+obj.getClass());
Exemplo ex= (Exemplo)obj;
ex.toString();
}

public Object novaCoisa() {
return new Exemplo();
}
}


O problema anterior é causado por falta de isolamento, objetos de classloaders no mesmo nível hierárquico jamaisdevem se comunicar, a aplicação deve garantir essa separação. Caso seja realmente necessária esta comunicação, ela deve ser feita via call-by-value, ou seja, serializando os objetos nas bordas.

O outro problema é o do espelho de duas direções, no qual uma classe enxerga a outra mas a recíproca é falsa. Isso ocorre quando uma classe carregada por um classloader mais próximo da raiz depende de uma classe que pode ser carregada apenas por um classloader mais distante. Como exemplo, dada as classes a seguir e dois classloader, Pai e Filho, vamos ver como isso acontece:


class VimDoPai {
public void print() {
System.out.println(new VimDoFilho());
}
}

class VimDoFilho {
public void print() {
System.out.println(new VimDoPai());
}
}


Vamos supor que o classloader Filho delega para Pai a carga de classes. Supondo que Filho carregue a classe VimDoFilho e Pai carregue VimDoPai, quando VimDoFilho.print() for chamado, o classloader Filho delega para Pai e consegue uma referencia para a classe VimDoPai, porém quando VimDoPai.print() é chamado, o classloader Pai não encontrará a classe VimDoFilho e um ClassNotFoundError irá acontecer.

No exemplo anterior podemos notar o motivo pelo quando o escopo do classloading é um problema difícil de decifrar. Quando uma classe é carregada por um dado classloader, todas suas dependências serão resolvidas através dele. Tratá-se de uma imposição draconiana, pois abre espaço para uma enorme gama de problemas, como o visto anteriormente. Mais grave é o fato de acabarmos com um sistema no qual objetos que interagem entre sí possuem visões divergentes dos tipos existentes. Infelizmente esta é uma limitação necessária para criar um sistema de tipos sonoro e seguro.

Classloading é um mecanismo muito interessante do Java, pois permite criar coisas fabulosas como o container OSGi, porém não deixa de ser a parte mais dolorosa da plataforma quando ocorrem problemas. Java não possui suporte a realmente isolar um classloader de outro, como outras plataformas possuem, e quando precisamos violar o mecanismo de delegação uma enorme quantidade de problemas podem acontecer.

Para entender o problema, vamos lembrar um pouco como Generics funciona com herança, temos as interfaces Foo<T> e Bar extends Foo<String>, os métodos de Foo que dependem de T vão, na verdade, usar Object, o mesmo acontece com Bar, que possui nenhum método a mais que Foo. Diferente do que acontece com classes, não são criados métodos sintéticos com a assinatura especializada, por exemplo, em Bla implements Comparable<Bla>, vamos ter um método sintético int compareTo(Bla b).

Qual a relação de erasure e métodos sintéticos com EJB3? Simples, em um Stateless Session Bean definimos as interfaces remota e local, mas não precisamos implementá-las. Isso cria uma espécie de ilusão de ótica, pois de um lado achamos que os métodos implementados possuem a assinatura correta e de outro, por conta do erasure, a assinatura é toda reduzida para Object. O resultado é um só, o container não localiza o método com a assinatura solicitada. O seguinte exemplo demonstra este problema:


public interface Foo {
T concat(T t1, T t2);
}

Podem testar este código, vão notar que o container reclama não consegue chamar Object concat(Object, Object). Nós queremos implementar o código utilizando o tipo especializado, só que para resolver isso vamos ter que jogar pelas regras do compilador e fazer BlaBean implementar Bla. Dessa forma, implementando a interface, o compilador vai aplicar erasure no bean também e a chamada do método vai funcionar corretamente.

Esta situação me ocorreu quando refatorei a interface de vários SLSB para usarem uma inteface base genérica. Quebrei a cabeça por um bom tempo até me ocorrer que o erasure do generics criou este problema, gostaria de ter encontrado uma solução melhor, mas a que apresentei aqui é um comprometimento razoavel. Meu gosto seria por uma solução da plataforma, como generics implementado direito, ou então uma atualização no RMI para levar reification em conta.

O maior argumento contra utilizar arquivos de configuração nunca foi muito o formato, seja xml ou qualquer outro, mas sim a quantidade abusiva de informação necessária para satisfazer o framework. Convenhamos, boa parte do tempo vamos usar apenas um conjunto pequeno dos recursos oferecidos e de uma maneira comum. Essas funcionalidades e interações recorrentes, devem possuir uma notação mais sucinta – o configuração deve ser ser otimizada para o uso comum. Para esse comportamento temos por uso de valores padrão inteligentes.

Porem, pode ser feito ainda mais. Neste caso, o framework assume que uma série de interações e padrões de uso serão utilizados e o usuário apenas configura aquilo que for diferente. Por esta maneira de trabalho, temos aquilo que chamamos por configuração por convenção. Juntando com valores padrão inteligentes, configuração deixa de ser uma preocupação, um martírio, para ser apenas um detalhe do projeto – que é seu devido lugar.

Em um cenário como esse, existe valor em expor uma extensa camada programática de acesso à configuração? Pelo resultado encontrado em vários projetos, sim, definitivamente existe, mas longe de ser uma boa ferramenta para substituir os arquivos. Primeiro, acho importante definir quais tipos de configuração existe em um framework e como isso afeta o valor ao abrir as portas para demais programadores.

Temos a Configuração de Inicialização, que pode ser vista como uma receita de bolo, que depois de utilizada, é descartada. O Hibernate é um bom exemplo, a configuração informada é utilizada para construir a SessionFactory e depois jogada fora. Outra forma de configuração é o Repositório de Parâmetros, onde toda configuração é armazenada de maneira que possa ser consultada em tempo de execução, o exemplo aqui fica por conta do Struts2, que transforma toda sua configuração em um modelo de objetos que representam os elementos envolvidos no processamento de uma requisição.

Das utilidades para configuração programática, destaco transformação, pois é aplicável no caso de Configuração de Inicialização. Transformação, como o nome sugere, altera a configuração já existente em algo mais útil, como colocar todas collections com lazy-loading; ou a partir de dados externos cria novos elementos, por exemplo, mapeando automaticamente todo um pacote de classes.

Quando existe um repositório, as possibilidades são maiores, o mecanismo de transformação pode ser aplicado na inicialização ou durante a execução. Para estender o comportamento do repositório utilizasse normalmente o padrão de projeto Plugin, para a descoberta do interessado, caso sejam muito, utiliza-se Chain-of-Responsibility para coordenar as transformações. O Struts2 funciona desta forma, é possível contribuir plugins que são responsáveis por instanciar as actions ou recuperar o mapeamento de um path. É possivel, por exemplo, descobrir quais actions existem no sistema e criar o mapeamento automaticamente.

Configuração programática é muito útil, porém não deixa de ser apenas uma ferramenta e, como tal, não deve ser o principal valor que um framework tem a oferecer, pois, a rigor, não trata do problema proposto a ser resolvido. Um framework MVC, por exemplo, deve ter como valores auxiliar no desenvolvimento de sites, dos quais configuração não é uma benéfice, mas sim um ardor maior ou menor para seu usuário.

Para entender melhor a situação, vejamos o modelo de execução que todo sistema operacional espera de seus processos. Um processo possui uma ou mais threads, cada thread possui apenas uma linha de execução* e faz chamadas bloqueantes ao kernel. Ou seja, cada uma deve seguir executando por apenas um caminho e deve parar enquanto uma chamada ao sistema não completa. Contrastemos agora com modelo de green-threads, que pode ser visto da seguinte forma: um processo possui uma ou mais threads, cada uma administra varias linhas de execução e uma chamada ao kernel não impede prosseguir com as demais.

Essa diferença de funcionamento gera dois problemas. Primeiro de identidade, já que cada thread não possui somente uma linha de execução associada, então primitivas de locking não funcionam pois duas green-thread vão aparecer para o kernel como uma só. O segundo está relacionado ao comportamento do kernel, uma chamada bloqueante partindo de uma linha de execução vai causar várias outras pararem junto.

Ambos problemas dificultam muito a integração com bibliotecas externas, que podem usar o mecanismo de locking do sistema operacional, ou então bloquear indevidamente demais threads. Por exemplo, no Gtk+, o acesso aos widgets é protegido por locks nativos, que em um ambiente com green-threads vai por água abaixo e acaba corrompendo o estado, também tem o fato que executar processamento pesado fora da thread de eventos não ajuda, pois se uma bloqueia, todas bloqueiam. Por fim, tem a questão da escalabilidade, já que várias threads são bloqueadas sem precisar.

Existem alguns sistemas que conseguiram transpor essas barreiras, mas não sem um alto custo associado. Passam, primeiro, a adotar uma primitiva de mais alto nível que uma thread, como um ator, que é muito mais simples de utilizar. Depois fazem o trabalho pesado, criam um mecanismo de execução assíncrona das tarefas bloqueantes, seja fazendo offload para threads nativas auxiliares, ou usando aio e/ou multiplexação. Por fim, partem para as medidas radicais, definindo uma interface para código estrangeiro que garante a semântica e o comportamento das green-threads.

A interface de integração com código estrangeiro, também conhecida por FFI (Foreign Function Interface), é o elemento mais crítico e problemático, pois precisa impor uma forma diferente de trabalho aos integradores, normalmente via troca assíncrona de mensagens entre uma thread com o código ‘perigoso’ e as demais gerenciadas. Uma versão muito mais cabeluda do JNI, para quem conhece.

Das linguagens que implementam efetivamente userland threading, que eu conheço são
Erlang, Scheme e Factor. Elas permitem o uso de milhares de thread leves que consomem poucos recursos e não fazem o escalonador do SO entrar em parafuso. A JVM da BEA, JRockit, uma época suportou green-threads, mas devido a dificuldade de implementar a parte GUI do Java e não criar caos durante chamadas nativas, desistiram do projeto quando o linux passou a ter suporte nativo descente.

* Por linha de execução entenda o conjunto de registradores e a pilha de funções.