LUA / Salvando tablas sin ciclos

Bienvenidos sean a este post, nuestra siguiente y mas dificil tarea es salvar las tablas que vinimos trabajando hasta ahora, hay muchas formas para guardarlas acorde a que restricciones tenemos sobre la estructura de nuestra tabla, ningun algoritmo es la unica opcion para todos los casos porque tablas simples no solamente necesitan algoritmos mas simples sino que el archivo resultante debe ser tambien lo mas estetico posible, veamos el siguiente codigo:

function serializar(o)
	if type(o) == "number" then
		io.write(o)
	elseif type(o) == "string" then
		io.write(string.format("%q",o))
	elseif type(o) == "table" then
		io.write("{\n")
		for k,v in pairs(o) do
			io.write("  ", k, " = ")
			serializar(v)
			io.write(",\n")
		end
		io.write("}\n")
	else
		error("No se puede serializar " .. type(o))
	end
end

Mas alla de la simplicidad de este codigo la funcion hace un trabajo razonable, porque evalua tres tipos de datos ejecuta sus instrucciones y si el tipo que recibe no coincide con ninguno de los tres nos lo notifica por medio de error, las dos primeras condiciones son las que vimos hasta ahora, en el caso de las tablas no solamente maneja las tablas comunes sino tambien las anidadas, correcto: tablas dentro de otras tablas, mientras que la estructura de la tabla sea un arbol, es decir que no haya subtablas compartidas ni ciclos, una pequeña mejora estetica seria formatear tablas anidadas ocasionales en C.

En la funcion previa asume que todas la claves en la tabla son identificadores validos, si la tabla tiene claves numericas o claves de cadenas que no sean identificadores validos sintacticamente en Lua nos va a poner en problemas, una simple solucion es cambiar la siguiente linea:

io.write("  ", k, " = ")

Por esta otra linea:

io.write("  ["); serializar(k); io.write("] = ")

Con este cambio no solamente mejoramos la robustez de nuestra funcion al costo de la estetica del archivo resultante, veamos el codigo final:

function serializar(o)
	if type(o) == "number" then
		io.write(o)
	elseif type(o) == "string" then
		io.write(string.format("%q",o))
	elseif type(o) == "table" then
		io.write("{\n")
		for k,v in pairs(o) do
			io.write("  ["); serializar(k); io.write("] = ")
			serializar(v)
			io.write(",\n")
		end
		io.write("}\n")
	else
		error("No se puede serializar " .. type(o))
	end
end

Pongamos en practica estos codigos, para ello usemos el siguiente ejemplo:

> serializar{ a=12, b='Lua', llave = 'otra "única"' }

Si usamos el primer codigo de serializar obtendremos una salida como esta:

{
  b = "Lua",
  a = 12,
  llave = "otra \"única\"",
}

Si a este mismo ejemplo lo probamos con el segundo codigo obtendremos esta salida:

{
  ["b"] = "Lua",
  ["a"] = 12,
  ["llave"] = "otra \"única\"",
}

Esta es basicamente la diferencia entre los dos codigos, aunque el segundo no sea tan estetico y practico como el primero si nos evitara inconvenientes inclusive con palabras reservadas, un poco lo que estuvimos hablando en los ultimos posts.

En resumen, hoy hemos visto el primero de los casos para salvar las tablas que generamos, como debe ser la estructura, como podemos trabajarlo en base al tipo informado, como se puede hacer de forma practica, y como hacerlo de forma correcta, espero les haya sido util sigueme en Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.