Objetos que se llaman, se imprimen y se miden: __call, __tostring y __len

Los metamétodos aritméticos responden a preguntas de cálculo. Los tres de esta lección responden a preguntas de identidad: qué es esta cosa cuando la invoco, qué es cuando la miro, qué es cuando la mido. Ninguno añade capacidad de cómputo y los tres cambian radicalmente la experiencia de usar un tipo. Con __call una tabla deja de distinguirse de una función; con __tostring tus objetos dejan de aparecer en las trazas como una dirección hexadecimal inútil; con __len el operador de longitud deja de depender de la maldita frontera de la parte secuencia y pasa a significar lo que tú decidas. Son, en la práctica, los tres metamétodos que más se notan.

Tablas que se comportan como funciones

Cuando Lua intenta llamar a un valor que no es una función, busca __call en su metatabla. Si lo encuentra, lo invoca pasándole el propio valor como primer argumento, seguido de los argumentos originales de la llamada. Es exactamente el mismo desplazamiento que produce la sintaxis de dos puntos en los métodos, pero aplicado a la llamada entera.

local function memoizar(f)
  local cache = {}
  return setmetatable({ aciertos = 0, fallos = 0 }, {
    __call = function(self, x)         -- self es la tabla; x, el argumento real
      local v = cache[x]
      if v == nil then
        self.fallos = self.fallos + 1
        v = f(x)
        cache[x] = v
      else
        self.aciertos = self.aciertos + 1
      end
      return v
    end,
  })
end

local lento = memoizar(function(n) return n * n end)
print(lento(4), lento(4))              -- 16  16
print(lento.aciertos, lento.fallos)    -- 1  1

flowchart TB
A[El programa escribe obj abre parentesis cierra parentesis] --> B[El valor es una funcion de verdad]
B --> C[Si lo es se llama directamente]
B --> D[Si no busca call en su metatabla]
D --> E[Si existe lo llama con el objeto como primer argumento]
E --> F[Detras van los argumentos originales de la llamada]
D --> G[Si no existe lanza attempt to call a table value]

Lo interesante no es el ahorro de cálculo sino la forma: el resultado se usa como una función y se inspecciona como una tabla. Un closure puro guarda su estado en variables locales que nadie de fuera puede leer ni modificar, y esa opacidad es una virtud cuando el estado es un secreto y un estorbo cuando es un dato de interés, como aquí lo son los contadores de aciertos y fallos. Una tabla con __call te da las dos caras del mismo valor: la operación en la línea de llamada y la estructura en la línea de inspección. De ahí que el patrón aparezca en todas partes: constructores que se invocan directamente sobre el módulo, comparadores con configuración, capas de red que son a la vez objeto y operación.

El caso más visible es el del módulo invocable. Una biblioteca de expresiones de coincidencia puede devolver una tabla con funciones auxiliares y, a la vez, dejar que el uso más frecuente se escriba invocando el módulo entero, sin nombrar ninguna función. La tabla sigue siendo el espacio de nombres de siempre; el __call solo añade un atajo para la operación principal, y quien no lo conozca puede ignorarlo por completo.

Representación y longitud

Los otros dos metamétodos se entienden mejor juntos, sobre un tipo que necesita ambos: una lista que guarda su propio recuento y por tanto admite agujeros.

local Lista = {}
Lista.__index = Lista

function Lista.nueva(...)
  return setmetatable({ n = select("#", ...), ... }, Lista)
end

function Lista:agregar(v)
  self.n = self.n + 1
  self[self.n] = v                     -- v puede ser nil sin romper el recuento
end

function Lista.__len(self)
  return self.n                        -- O de uno, y sin frontera ambigua
end

function Lista.__tostring(self)
  local partes = {}
  for i = 1, self.n do partes[i] = tostring(self[i]) end
  return "Lista[" .. table.concat(partes, ", ") .. "]"
end

local l = Lista.nueva(10, nil, 30)
l:agregar(nil)
print(l)          -- Lista[10, nil, 30, nil]
print(#l)         -- 4
print(rawlen(l))  -- 3 o 1: la frontera cruda, impredecible con agujeros

La longitud que devuelva __len debe ser un entero cuando la consume la biblioteca de tablas; un flotante con parte fraccionaria o una cadena provocan un error de longitud no entera. Y conviene recordar que las cadenas ignoran el metamétodo por completo: la longitud de una cadena es siempre su número de bytes, aunque alguien manipule la metatabla compartida de las cadenas.

Cuándo no usarlos

Los tres son azúcar, y el azúcar tiene coste. Un __call convierte en invisible el hecho de que hay una tabla con estado detrás de lo que parece una función pura, y quien lea el código en la línea de llamada no tiene forma de saberlo. Un __tostring que trunque o embellezca demasiado puede ocultar precisamente el dato que necesitabas en una traza a las tres de la mañana. Y un __len que no coincida con el recorrido natural del objeto crea dos verdades sobre el mismo valor, que es la peor situación posible.

La regla práctica es sencilla: usa __tostring casi siempre, porque el coste de no tenerlo lo pagas depurando; usa __len cuando tu tipo tenga un tamaño inequívoco que la frontera cruda no puede calcular; y usa __call solo cuando el valor sea conceptualmente una operación y no un contenedor que casualmente sabe hacer algo.

Hay además una consideración de rendimiento que conviene tener presente aunque rara vez decida nada. Los tres metamétodos convierten una operación que el intérprete resuelve en unas pocas instrucciones de su máquina virtual en una llamada a Lua completa, con su marco de pila y su retorno. En un bucle que mida la longitud un millón de veces, la diferencia se nota; en el noventa y nueve por ciento del código, no. La respuesta profesional a esa tensión no es renunciar al metamétodo sino guardar el resultado en una variable local antes del bucle, que es lo que habría que hacer igualmente con una llamada normal.