[Jellinghaus90] apresenta uma experiência onde se incorporam as primitivas Linda em Eiffel. O modelo implementa a classe TUPLE, onde são definidos os equivalentes das primitivas Linda in, rd e eval. Assim, tuplas são objetos da linguagem, e as primitivas Linda são métodos de instância em Eiffel.
A noção de classe, em Eiffel, deixa de existir em tempo de execução. Segundo [Meyer8 8], classes têm existência em tempo de compilação, e instâncias em tempo de execução! Justamente a impossibilidade de expressar informações sobre classes dificulta a definição de formais em Linda. Aqui, o autor optou por identificar os formais através de v o id 49. Sendo um formal um identificador de algo a ser aceito (uma instância de determinada classe) no
casamento, uma referência void poderia retomar justamente a instância a ser aceita após o casamento das tuplas. Como os tipos INTEGER, etc50 não são referências em Eiffel, eles nunca provocarão casamento com o formal void (que é uma referência vazia). Isso faz com que tais objetos de "tipos primitivos" somente casem com outro exatamente igual (casamento de parâmetro real com parâmetro real). Para poder possibilitar formal para os chamados tipos primitivos, é necessário definir, em Eiffel, uma classe para cada um dos tipos primitivos. No caso de INTEGER, por exemplo, seria necessário uma classe CLASSE_INTEGER. Referencias void desta classe seriam consideradas formais que casariam com instâncias desta classe. Assim, cada INTEGER deveria ser transformado em instância de CLASSE INTEGER para depois ser inserido em tuplas para termos a potencialidade de expressar formais para tais tipos.
Um levantamento aprofundado de plataformas que suportam Linda pode ser encontrado em [Carriero89a],
49 Void é equivalente a um pointeiro nulo - NIL em Modula-2. 50 Tipos "primitivos"em outras linguagens.
A otimização das tuplas para posterior casamento, como é usualmente feito pelo pré-compilador C-Linda, não se faz necessário em Eiffel Linda. Aqui, através de asserções [Meyer8 8] e o mecanismo de classificação, a condição de casamento pode ser garantida. A forte tipagem de Eiffel continua sendo válida para as novas classes que formam o modelo Linda.
A possibilidade de definir tuplas, cujos campos podem conter virtualmente qualquer objeto da linguagem, traz problemas conhecidos no modelo Linda. Um campo de uma tupla poderia conter, por exemplo, uma estrutura de dados (árvore, por exemplo).A estruturá poderá conter objetos compartilhados por outras estruturas, conforme a figura que segue:
Figura 6.1 - Objetos Compartilhados em Tuplas
Ao ser colocada no espaço de tuplas, esta tupla deve carregar os objetos que contém, propriamente falando, e não apenas as referências. Isso se deve ao fato de que referências são usualmente ponteiros (pointers), que têm sentido apenas em um único espaço de endereçamento. No caso de Linda, vários processos podem estar cooperando, cada qual em um espaço de endereçamento distinto. Esta possibilidade de distribuição toma crítico o uso de ponteiros no modelo Linda.
A técnica adotada aqui é copiar toda a estrutura da referência, através da funcionalidade da classe STORABLE de Eiffel. Desta forma, todo o grafo de referências de cada um dos sub-objetos é copiado para o espaço de tuplas. Comunicação através do espaço de tuplas têm, então, a semântica de cópia. Um objeto de uma tupla produzida com out, por exemplo, será copiado para o contexto de outro processo que evoque in ou rd. Agora dois parâmetros reais apenas casam se as suas estruturas são completamente iguais, conforme armazenado através da funcionalidade de STORABLE. Ciclos no grafo de referência são detectados apropriadamente pela implementação.
A sintaxe das operações fica um pouco diferente, por exemplo, de C-Linda. Seja x um objeto Eiffel que represente uma tupla, as "primitivas" Linda surgiriam da seguinte forma:
X . out
x. in
Listagem 6.1 - Sintaxe Eiffel Linda
Neste último caso, seguindo a filosofia Eiffel, a operação não apresenta efeitos colaterais. Desta forma, o programador precisa acessar explicitamente os campos com novos objetos resultantes do casamento, uma vez que não há alteração das variáveis locais que integram tuplas, conforme ocorre com C-Linda.
Finalmente, a operaçao eval e definida também na classe TTJPLE. A princípio, esta operação não faz praticamente nada. O programador deve adicionar subclasses de TXJPLE, redefinindo a operação eval para cada nova classe adicionada. Ao ser terminada a computação de eval definida na nova subclasse, a tupla é automaticamente 51 adicionada ao espaço de tuplas. E importante notar a grande perda de expressão em relação ao modelo Linda original. Por exemplo, em C-Linda é possível:
eval ( find(letfTree, 55) , find (rightTree, 99) k
Aqui, serão executados em paralelo as duas operações de pesquisa, cada qual em uma sub-árvore. Haverá, ainda, uma sincronização das duas atividades, uma vez que somente após as duas operações terem sido terminadas é que a tupla viva transforma-se em tupla ordinária, sendo adicionada ao espaço de tuplas. Na implementação Eiffel Linda, a redefinição de eval em uma nova subclasse forçaria o programador a:
1) Definir uma subclasse de TUPLE somente para efetuar tal operação eval 2) Escolher uma dentre duas formas de avaliar as duas operações de pesquisa:
a) Efetuá-las uma de cada vez, perdendo a oportunidade de paralelizar tal busca através da potencialidade do modelo.
b) Através de um outro recurso de Eiffel, disparar dois sub-processos, um para cada pesquisa, e implementar alguma forma de sincronização entre os mesmos. Somente após terminadas as duas operações de busca o processo original {eval da nova classe definida) poderá continuar, para que a tupla seja inserida no espaço de tuplas. Esta abordagem contraria justamente a elegância que o modelo propõe, forçando o programador a ter que utilizar um
segundo método ainda para disparar e sincronizar processos.
A utilização de objetos para implementar tuplas, por outro lado, permite que tuplas possam ser atribuídas a variáveis, passadas como parâmetro, etc, ou seja, tratadas de forma uniforme na linguagem. Mais além, sendo os parâmetros formais objetos da linguagem, eles podem também ser tratados da mesma forma, podendo também haver casamento entre formais.
Objetos distribuídos podem ser implementados através de novas classes em Eiffel. Por exemplo, ARRAYDISTRIBUIDO , LISTA DISTRIBUIDA, etc podem ser implementados sobre as tuplas Linda, cuja distribuição faz parte do modelo. Esta é uma potencialidade a ser
explorada, que depende da implementação realmente distribuída do espaço de tuplas. O autor aponta alguns problemas desta abordagem em relação à forte tipagem de Eiffel, aliado ao fato de a igualdade escolhida para efeitos de casamento ser estrutural. O autor sugere o método
match a ser definido para instâncias de tuplas, mas não optou por esta implementação devido à
sua maior complexidade e perda de performance.
Eiffel Linda foi originalmente implementado sobre uma rede de estações de trabalho SUN, utilizando o kemel Linda TSnet [Arango89], Sua intenção não era provar eficiência do modelo Linda, o que já é demonstrado por C-Linda, mas sim investigar as potencialidades/limitações da combinação do modelo de objetos de uma linguagem tipada como Eiffel e Linda. O autor ressalta ainda algumas limitações na distribuição de executáveis Eiffel distintos que precisem interagir através do espaço de tuplas. Isso ocorre devido ao identificador interno que Eiffel associa a cada objeto, que deve ser uniforme caso tais objetos sejam espalhados através de uma rede de estações de trabalho. A primitiva eval, por outro lado, ainda não havia sido implementada até a data da publicação do trabalho.