使用 table 作为 __index 似乎更合理

[jojo59516]

当前版本的 tracedoc 利用 _lastversion 保存原始信息，利用 _keys 和 _changes 保存修改信息。这导致一个 tracedoc 对象的“newestversion”信息分散在上述两部分里，它导致了：

• tracedoc 对象的 index 元方法必须是一个函数；
• len、ipairs、pairs 等元方法的实现很复杂，必须手写逻辑完成“先查修改部分，没有再查原始部分”的操作。

而反过来，将“newestverison”保存在一个 table 中（可以称之为 _stage，取名灵感来源于 git），将该 table 设为 tracedoc 对象的 index 元方法，依然利用另外两个表 _changed_keys 和 _changed_values 保存原始信息。这样一来：

• 对当前的 tracedoc.commit、tracedoc.mapchange 等方法的实现改动很小；
• 可以加速去读速度（表的读取快于函数调用）；
• 更重要的是，len、ipairs、pairs 等元方法，甚至 concat、unpack 等 table 的方法都可以很方便地实现，只需要做一个转发调用即可。如 pairs 元方法可以定义为：

local function doc_pairs(doc)
	return pairs(doc._stage)
end

以上优化思路，我在自己的分支下已经验证了其可行性和表读取方面的优化效果。

[cloudwu]

有道理。不过我最近没精力做次修改，且这个东西用在生产环境，需要谨慎 review 。

你可以先提一个 pr 。

btw, 最早 doc 的 __index 的确是一个 table , 后来才演化出现在的版本。应该是一开始没考虑周全。