想再讨论下 stringify

[constly]

之前我发表过一些疑问 关于stringify的疑问

现在我又遇到一个问题，下面这个tb无法被序列化

local tb = {"and", {"owner", "hp", ">=", 1}, {"owner", "hp", "<=", 100} }
local str = serialize.stringify(tb)

我试了下也看了下源码，对于顺序数组的情况，程序会严格递归判断第一个元素的类型，如果是table，那后面也得是table，如果第一个不是table，那后面也不能有table，否则就会报错或者数据被忽略。

所以，下面这个tb也是无法被序列化的，虽然第一层元素都是table，但第二层数据类型不一致

local tb = {{"and"}, {{"or"}, {"owner", "mp", ">=", 1}, {"owner", "hp", "<=", 1}}, {"owner", "hp", "<=", 100} }
local str = serialize.stringify(tb)

我想表达的是：
上面这个规则确实有利于： “将数据转换为其它标记语言表示” 。
但是，从使用者的情况来看，不是每一个人都有这个需求呀，为什么要遵守这个规则呢？

是否可以这样考虑：在序列化时尽量兼容lua的特性，如果使用者有转换为其他语言的需求，自己在序列化时注意下格式呢？

[actboy168]

ant.serialize这个包的名字可能有一定的误导性，但相关的回答，上一个讨论已经说得很清晰了。不过我还可以再重复一次。

datalist是被设计为便于阅读和手写的一个数据格式。任何时候都不要试图将某一个lua的table转为datalist格式(或者称之为序列化？)。这跟json、ini、xml之类的格式是一样的，显然不会有人觉得某一个lua的table不能转为一个json是json的问题。

[constly]

好的~ 不过长远来看，目前这个规则对策划 或者 玩家(做mod)来说 不太友好，容易混用，一混用就容易滋生解析报错

[cloudwu]

我刚才顺手改了一下 datalist 这个子项目，把 tab 设定为 4 (宏控制) 。之前 tab 相当于 1 space 。

cloudwu/datalist@df30ac9

我没测试，你可以先单独自己更新 datalist 到最新看看是不是对了。

等我明天有空也测试一下，就更新 ant 里的子模块。

[cloudwu]

btw, 略微降低了一点点解析性能。原本两个指针一减就知道缩进多少，现在需要再检查一遍文本。

[cloudwu]

我也给很多游戏做 mod ，其实我的经验是，玩家对 mod 的格式容忍度挺高。如果要求 tab space 不可以混用，那么玩家多能接受。
而且一般出现 tab/space 混用，其实容易滋生 bug 。因为在这个数据格式里，缩进是有具体层级含义的。

[constly]

我刚才更新测试了下，OK了~

[constly]

我最终改了一个我期望的版本，支持将:

local tb = {
	node = { 
		conditions = {"and", {"or", {"hp", ">=", 2}, {"hp", "<=", 100}}, {"or", {"mp", ">=", 4}, {"mp", "<=", 10}}}, 
		effect = {{"mp", "+=", 2}, {"hp", "-=", 2}} 
	}
}

保存为文本:

node:
  conditions:
    and, {or, {hp, ">=", 2}, {hp, "<=", 100}}, {or, {mp, ">=", 4}, {mp, "<=", 10}}
  effect:
    {mp, "+=", 2}, {hp, "-=", 2}

datalist自身可以正确将保存后的文本还原为原始table，所以这样做没问题~

其他人如果有兴趣的话，可以参考下我对stringify.lua的改动(复制了一份到我的项目中)：

1. 加了一个函数递归判断是不是简单数组: is_simple_array_recursively(v)
2. 在stringify_array和stringify_中，优先判断当前处理的是不是简单数组，如果是，则单独处理

示例代码如下:

-- 这是新增函数，用于递归将table中的元素转为为string
local function parse_simple_table(v, depth)
	if type(v) == "table" then 
		local s = {}
		for i, v in ipairs(v) do 
			s[i] = parse_simple_table(v, depth + 1)
		end
		if depth == 0 then 
			return table.concat(s, ", ")
		else 
			return "{" .. table.concat(s, ", ") .. "}"
		end
	else
		return stringify_basetype(v)
	end
end

-- 修改原有函数
local function stringify_array(n, prefix, t)
       -- 此处是新增逻辑
	if is_simple_array_recursively(t) then 
		out[#out+1] = indent(n)..prefix
		out[#out+1] = indent(n + 1) .. parse_simple_table(t, 0)
	else 
		-- 这里是原始逻辑
	end
end

-- 修改原有函数
function stringify_(n, data)
    if isArray(data) then
               -- 此处是新增逻辑
		if is_simple_array_recursively(data) then 
			out[#out+1] = indent(n) .. parse_simple_table(data, 0)
		else 
			-- 这里是原始逻辑
		end
    else
        -- 这里是原始逻辑
    end
end

我目前只是大概测试了下没啥问题，后续会持续使用关注下~

[cloudwu]

看到这个，我想到个题外话。

目前 datalist 的语法里面， = 和 : 两个符号是等价的。最早设计的时候是希望提供一定的弹性，可以把 x : 1 写成 x = 1 ，或许在某些配置文件里看起来会好看一点。

但 Ant 实际使用的时候，没有使用过 = 的写法。

如果我们把这个 = 的替代语法去掉的话，>= <= 这样的符号就不需要加引号了。不知道有没有意义。

[cloudwu]

刚才我更新了一下 cloudwu/datalist@8bd1f5e
现在应该可以不用给 += 这些加引号了。

[cloudwu]

现在可以写成

{and  {or  {hp  >  2} , {hp <= 100}}, {or {mp  >=  4}, {mp <= 10}}}

逗号和空格一直都是可互替的。hp <= 100 或许你会更喜欢一点。

[constly]

噢，怪不得，我开始还在疑惑，为啥只有这种字符 ">=" 才有引号。
我觉得去掉=写法是有意义的，统一语法规范更便于维护和传播~

[constly]

嗯，我上面这种情形确实{hp <= 100} 要比 {hp, <=, 100} 看起来舒服，不过我是在我的工具库里面统一写的datalist的序列化和反序列化，用逗号分割感觉更通用明晰一些。
说点题外的，我最初看datalist文件的时候，感觉有点怪怪的，后面真正用了后，发现这个真是太简洁明了了，很不错！