AkitaOnRails

push_iv_4 # empurra a variável de instância

1. nr. 4 para a pilha
   store_and_pop_iv_6 # armazena o topo da pilha na
2. variável de instância nr. 6

Em Smalltalk, esses números de índice mágicos usados para acessar variáveis de instância são determinados quando a definição de classe é salva. Nesse caso "b" acaba sendo a 4a. variável de instância, e "a" a 6a. Bytecodes Smalltalk são otimizados para objetos pequenos, as primeiras 16 variáveis de instância podem ser todas empurradas ou puxadas com uma única instrução de um byte, e se um objeto tem mais do que 16 variáveis de instância então eles precisam ser acessados através de uma instrução push ou store extendidas, que permite acessar até 64 variáveis de instância.

Em Smalltalk, embora variáveis de instância não sejam *tipadas*, elas são *declaradas* em uma mensagem de definição de classe executada quando a definição é salva. Toda vez que uma definição de classe é salva, os índices para as variáveis de instância dessa classe, e de qualquer sub-classe são (re)computadas, e quaisquer métodos na classe e sub-classes são recompilados para ajustar os offsets. As variáveis de instância definidas na classe mais ao topo recebem os primeiros n offsets, cada sub-classe imediata recebem offsets seqüenciais começando com a próxima disponível, e assim por diante.

Isso é porque eu disse acima que dentro de um objeto Smalltalk, ou seja, dentro de seus métodos, o objeto é mapeado estaticamente. Mudar a definição das variáveis de instância requerem recompilação para evitar "erros de tipos" nos métodos.

Note que aqueles métodos "apenas para emergências" instVarAt: e instVarAt:put: mapeiam para bytecodes push_iv e store_and_pop_iv, o primeiro argumento para ambas é o índice da variável de instância. Isso também significa que elas precisam ser usadas com cuidado, já que você precisa saber o offset da variável de instância. Agora, pelo menos Smalltalk pode lhe dizer se tentar acessar um slot de variável de instância que não existe mas ele não pode lhe dizer que está acessando o slot *errado*.

h3. Ligação de Campo de Java

Em Java, offsets não são compilados diretamente nos bytecodes, existe um nível de indireção. Peter Haggar, com quem trabalhei na IBM escreveu um "artigo sobre bytecodes Java":https://www.ibm.com/developerworks/ibm/library/it-haggar_bytecode/ na developerWorks. Espero que ele não se incomode se eu pegar emprestado um de seus exemplos. Aqui vai um simples método de acesso:

--- java
public String employeeName() {
        return name;
}

E os bytecodes resultantes. (O 0, 1 e 4 são offsets a partir do começo do método)

Method java.lang.String employeeName()
0 aload_0
1 getfield #5 <Field java.lang.String name>
4 areturn

O que esse código faz primeiro é empurrar a referência do objeto corrente this, para a pilha. Então a instrução getfield usa seu operando para substituir os dois ítems mais ao topo da pilha com o valor do campo. Então esses dois bytecodes (na realidade 3 bytes no total) são mais ou menos equivalentes ao bytecode push_iv do Smalltalk, com apenas duas diferenças:

1. O opcode push_iv do Smalltalk implicitamente usa o receptor do método corrente, ao passo que o opcode getfield precisa de outro argumento referenciando o objeto que tem a variável de instância sendo acessada
2. No Smalltalk o argumento identificando a variável é um índice inteiro, mas em Java o argumento é na realidade uma referência a um descritor de campo associado com a classe do objeto cuja variável de instância está sendo referenciada.

A primeira diferença é porque em Java, ao contrário de Smalltalk, você pode diretamente ler e escrever (get e set) campos públicos fora dos métodos do objeto, então já que o objeto em questão não está implícito, ele precisa ser especificado.

A segunda diferença é permitir uma compilação separada. A especificação da JVM não dita como campos são mapeados dentro de objetos, mas a abstração é permitir que esse mapeamento seja ajustado no momento em que classes são carregadas. Se uma sub-classe é compilada separadamente de sua superclasse, ele pode receber uma nova posição de início para seus campos toda vez que é carregada se sua superclasse adicionou ou removeu campos.

Então, para poder acessar campos em Java, o compilador precisa saber o tipo do objeto contendo o campo. Isso é verdade estando dentro ou fora de um método.

Variáveis de Instância, no Jeito Ruby

Em Ruby, variáveis de instância não são declaradas, então offsets não podem ser assinaladas estaticamente. Em vez disso, Ruby as procura dinamicamente, usando nomes de variáveis de instância em vez de um offset. Novamente isso bate com as mensagens de ‘uso de emergência’. instance_variable_get e instance_variable_set recebem um nome de variável de instância, completo com o sinal de ‘@’, onde os métodos instVarAt: recebem um inteiro.

Em Ruby 1.8, essa procura é implementada de maneira razoavelmente direta. Com poucas exceções, que não vou detalhar aqui, um objeto Ruby tem um ponteiro nomeado iv_tbl que aponta para uma tabela hash que mapeia os nomes das variáveis de instância a valores. Em Ruby 1.9, a implementação é um pouco mais esperta, mas os efeitos são os mesmos.

Então que variáveis São elas afinal?

O que nos leva de volta ao título do artigo. Em Java e Smalltalk, cada instância de uma dada classe tem os mesmos conjuntos de variáveis de instância, embora cada qual com seu próprio valor. As variáveis vêm à existência quando são declaradas, e a classe é compilada ou a definição é salva.

Uma coisa que não mencionei na discussão de Smalltalk é que, por causa da maneira tradicional onde implementações Smalltalk não separam ambiente de desenvolvimento do ambiente de run-time, quando uma definição de classe muda, além de necessitar da recompilação do método para a classe e suas sub-classes, quaisquer variáveis de instância precisam ser mutadas para ou adicionar ou remover as variáveis modificadas.

Lá atrás, quando ele estava trabalhando na linguagem Self, que tem resolução dinâmica de variáveis de instância como Ruby, Dave Ungar costumava gostar de matar várias implementações de Smalltalk adicionando uma variáveis de instância da classe Object. O problema é que como estamos tentando operar em um sistema vivo, o sistema normalmente tropeça em si mesmo durante esse tipo de operação. Eu tentei isso algumas semanas atrás com Squeak, e embora ele tenha me alertado duas vezes que eu não deveria fazer isso, ele tentou ir em frente depois que cliquei aquele segundo botão “Você tem certeza?”, e ele deu crash rapidamente. Ruby trata isso como uma coisa de curso, já que variáveis de instância são apenas adicionadas a objetos individuais quando são necessárias, e Self dentro de um método realmente é duck-typed, na verdade mais do que duck-typed, já que variáveis de instância necessárias aparecem instantaneamente.

Então você menciona o Pattern Observer. O que isso tudo tem a ver com aquilo?

Uma das coisas que me deixou pensando sobre isso novamente foi uma conversa no ruby-talk algumas semanas atrás sobre garbage collection no Ruby e algumas das coisas que não deixavam um Object ser considerado lixo e ser coletado. O GC do Ruby tende a ter problemas se você usa finalização e não é realmente cuidadoso sobre como define seus finalizadores.

Um dos truques clássicos em Smalltalk nessa veia é a implementação de dependência de Objects, também chamado de, o Pattern Observer. Smalltalk fornece um mecanismo para adicionar objetos dependentes a qualquer objeto que, quando quer notificar seus dependentes que ele mudou, pode simplesmente uma mensagem de mudança a si mesmo, que por sua vez envia a atualização de mensagem a cada objeto dependente: com o objeto modificado como o argumento.

Essa é a base para o design de Model View Controller em Smalltalk. Views se registram como dependentes dos Models, e quando um Model muda, quaisquer Views dependentes dele podem reagir. Essa é a gênese do pattern Observer do bem conhecido livro de Design Patterns da Gang of Four onde Model e View foram generalizados a Subject e Observer, respectivamente.

Em Smalltalk a habilidade de gerenciar uma lista de dependentes e notificá-los de mudanças é algo que todo objeto pode fazer, mas muito poucos realmente usam essa capacidade. Para evitar ter uma variável de instância em todo objeto Smalltalk referenciar uma coleção de dependentes que está quase vazia, a implementação padrão realmente mantém um hash global que mapeia objetos com dependentes à sua coleção de dependentes.

O problema com essa implementação padrão é que uma vez que um objeto ganha um dependente, o objeto e seus objetos dependentes estão permanentemente acessíveis e, portanto, inelegíveis para garbage collection, a menos que a dependência seja explicitamente removida. Como resultado disso, as classes da maioria dos objetos que realmente tem dependentes reimplementam os métodos padrão para se referir a coleções de dependentes via um valor de instância no objeto com dependentes. Squeak, por exemplo, fornece uma subclasse de objetos chamada Model que fornece esse tipo de implementação amigável a GC.

O que me leva à implementação do pattern observer em Ruby. Em sua discussão desse pattern em seu livro, Russ Olsen fornece um módulo que pode ser misturado (mixed) em um objeto para permitir que ele tenha dependentes:

module Subject
  def initialize
    @observers = []
  end

  def add_observer(&observer)
    @observers << observer
  end

  def delete_observer(observer)
    @observers.delete(observer)
  end

  def notify_observers
    @observers.each do |observer|
      observer.call(self)
    end
  end  
end

Esse é um bom exemplo do pattern em Ruby, onde os Observers podem ser blocos, ou qualquer objeto que responda ao método ‘call’ e que leve o Subject como seu argumento.

Pouco antes de ver o livro, como resultado da conversa sobre GC, eu escrevi minha própria variação disso, que deixa qualquer objeto ser um subject, abrindo a classe Object:

class Object
    def add_observer(&observer)
      (@observers ||= []) << observer
    end

    def delete_observer(observer)
      observers.delete(observer)
    end

    def notify_observers
      observers.each do |observer|
        observer.call(self)
      end
    end

    private
    def observers
      @observers || []
    end 
end

Por causa do fato que Ruby apenas adiciona variáveis de instância on the fly quando necessário, ganhamos o benefício de suporte universal a objetos serem Subjects sem requerer uma variável de instância de observers para os objetos que não precisam disso. O único custo é a potencial colisão de namespace para os quatro nomes de métodos.

Outro uso de variáveis de instância dinâmicas

Recentemente escrevi um artigo para a InfoQ sobre o plugin resource_controller de James Golick para Rails que lhe permite escrever controllers de Rails para recursos Restful que podem automaticamente se adaptar a uso em diferentes contextos de aninhamento de recursos. Esse plugin faz bom uso da natureza dinâmica das variáveis de instância do Ruby, automaticamente definindo diferentes variáveis de instância no controller para corresponder ao recurso final e cada um de seus recursos pais.

Ufa!

Isso acabou virando um artigo bem longo, que eu queria escrever havia algum tempo. Espero que alguém ache isso útil, ou pelo menos interessante.

tags: learning ruby smalltalk java beginner