当前版本的 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
以上优化思路，我在自己的分支下已经验证了其可行性和表读取方面的优化效果。
当前版本的 tracedoc 利用
_lastversion保存原始信息，利用_keys和_changes保存修改信息。这导致一个 tracedoc 对象的“newestversion”信息分散在上述两部分里，它导致了：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元方法可以定义为：以上优化思路，我在自己的分支下已经验证了其可行性和表读取方面的优化效果。