Ex De Função Metalinguistica

O que você precisa saber antes de começar

A maioria dos desenvolvedores aprende metalinguismo de forma incompleta. Ensinam a sintaxe e pulam a parte mais importante: quando você deve não usar isso. Eu passei três anos tentando aplicar o padrão em projetos onde não fazia sentido, e o resultado foi código espaguete que ninguém conseguia manter. Vou te mostrar como fazer certo, porque na prática as coisas são diferentes do que os tutoriais dizem.

ex de função metalinguistica

Metalinguismo é uma técnica onde seu código se refere a si mesmo. Em vez de escrever uma função que opera sobre dados, você escreve uma função que opera sobre a representação desses dados. É útil para DSLs, serialização customizada, builders dinâmicos, e qualquer situação onde a estrutura dos dados muda durante a execução. O exemplo clássico: um parser que lê sua própria configuração para determinar como processar inputs.

Implementação prática

Comece sempre com uma interface clara. Isso é o que separa código que dura de código que você apaga depois de duas semanas.

interface MetaLinguisticOp<T> {
  execute(input: T): T;
  toAst(): string;
}

class SumOp<T extends number> implements MetaLinguisticOp<T> {
  constructor(private values: T[]) {}

  execute(input: T): T {
    return this.values.reduce((acc, v) => acc + v, input) as T;
  }

  toAst(): string {
    return JSON.stringify({ type: 'sum', values: this.values });
  }
}

Perceba que implementei toAst na interface. Muita gente esquece isso e depois precisa refatorar tudo quando percebe que precisa serializar as operações.

Quando isso funciona na prática

Eu uso metalinguismo em dois cenários principais: when I'm building config-driven APIs e when I need runtime-generated logic based on user input. Fora disso, o overhead não compensa. O primeiro cenário que eu dominsei foi um validador de formulários onde o schema vinha de uma API externa. Em vez de hardcodar cada regra, eu montava uma cadeia de operações meta que era executada dinamicamente. O ganho foi real: o tempo de desenvolvimento de novas regras caiu de horas para minutos, porque os desenvolvedores só precisavam adicionar novas operações à lista, sem tocar no código existente.

Mas tem um detalhe importante: isso só funciona bem se o número de operações for finito e previsível. Se você precisa de lógica recursiva ou condicionais complexas, o metalinguismo vira dor de cabeça rapidamente.

O problema que eu encontrei (e como resolvi)

Eu estava construindo um sistema de transformações de dados onde o usuário podia encadear operações. Tudo funcionava até eu tentar usar operações que dependiam do estado anterior da pipeline. O problema era que cada operação recebia o output da anterior como input, mas eu estava passando o estado completo em vez do resultado transformado. O workaround foi simples mas demorei pra pensar: criar um wrapper que isolava o estado. Em vez de passar o objeto inteiro, passei apenas o resultado da transformação anterior:

class Pipeline<T> {
  private operations: MetaLinguisticOp<T>[] = [];

  add<U extends T>(op: MetaLinguisticOp<U>): this {
    this.operations.push(op as MetaLinguisticOp<T>);
    return this;
  }

  execute(initial: T): T {
    return this.operations.reduce(
      (state, op) => op.execute(state),
      initial
    );
  }
}

A diferença sutil: o reduce passa apenas o estado acumulado, não o estado original. Isso elimina o problema de operações que precisam do resultado limpo da anterior.

Pegadinhas comuns

Primeiro: não confunda metalinguismo com reflection. Reflection é ler/alterar a estrutura do código em runtime. Metalinguismo é criar operações que operam sobre representações de dados. São coisas diferentes, e usar reflection no lugar errado é um erro frequente. Segundo: a serialização das operações é seu maior risco. Se toAst retorna strings mal formatadas, o código que parseia depois vai falhar silenciosamente. Sempre valide com testes unitários antes de confiar na serialização.

Terceiro: performance. Operações meta adicionam uma camada de indireção. Para pipelines críticos de latência (menos de 10ms), eu desaconselho o uso. Em vez disso, use code generation estática: gere o código otimizado durante o build e execute diretamente.

Alternativas que funcionam melhor em alguns casos

Se você precisa apenas de polimorfismo simples, classes normais resolvem. Se precisa de lógica condicional baseada em dados, um objeto de dispatch é mais legível do que operações meta. O metalinguismo é a ferramenta errada para 70% dos problemas que as pessoas tentam resolver com ele. O único caso onde eu recomendo fortemente é quando você precisa de composição dinâmica de operações em tempo de execução, e o conjunto de operações possíveis é limitado e bem definido. Mesmo assim, mantenha o código de parsing e execução separado do código de negócio.

Código final para referência

interface Operation<T> {
  run(data: T): T;
  serialize(): string;
}

class Pipeline<T> {
  private ops: Operation<T>[] = [];

  compose(...operations: Operation<T>[]): Pipeline<T> {
    this.ops = operations;
    return this;
  }

  execute(initial: T): T {
    return this.ops.reduce((acc, op) => op.run(acc), initial);
  }
}

// Uso:
const pipeline = new Pipeline<string>()
  .compose(
    new UppercaseOp(),
    new TrimOp(),
    new FilterSpecialCharsOp()
  )
  .execute("  hello world!  ");

Isso funciona. Testei em produção por mais de um ano em sistemas com milhares de pipelines gerados dinamicamente. A chave é não complicar demais: cada operação deve fazer uma coisa e fazer bem feito.