这么一看我就是太弱智了才在codegen支持上花这么多时间，明明是一个毫无难度的东西，竟然浪费了我那么多看片的时间，罪过罪过…… 欲哭无泪

这个算法的名字就是 value-name substitution ，我一开始就明白，却想了半天才得出结论

对了，生成的代码貌似是按后序遍历排序的，尽管这个是基于副作用build str

呃……看起来应该还能用 (patchy 吧) 我有点不想写 GTK 支持了

#Python 真是无法保证这样复杂的时序写对…… 在有了Kotlin以后我不会在区间开闭上出错 但时序变量更新还真不能保证。（据说bug还是因为我顺手简化"无用赋值"导致的） 我不想写下去了，花了好大精力还熬了三天夜……刚刚有点好转

总感觉可以优化，总感觉看着让人觉得要删掉，可按顺序看看倒也没什么，可是关键在于把它删掉看着也没什么…… 直觉要好啊

注：是指 expr = get() ; if (expr == null) { expr = get1(); if (expr != null) bla() } 这种看起来怎么这么相似的

第一个从生成的代码创建出的Tk frame

太赞了！我居然做出了这种框架…… 等等，这样又如何呢emm

我准备发布了，发布后就会死掉。 不过对我来说这个无所谓（
加了一些东西(command 参数的 self 的编号, dict.findKey) 又因为实现不了而删了，心里不开心，现在放假了。

草这样不至于吧， Python 里 [for] {for} 都是对应数据的 genexpr ，没想到 () 居然不是 tuple 的 genexpr ……

类似表达式的后序遍历果然不行，需要的变量定义顺序很不对啊（而且这里好像不支持属性访问语法一样）...

看来只能用很脏的全局变量了…… 反正组件树是后序遍历的，那它依赖 但要调用创建它 所以必须提前的东西 就只能用全局变量了…… 不知道会不会有数据竞争之类的问题（但如果有说明应用的代码太飘了……）

有了这个以后，不知道 Codegen 的 autoExpr 该不该留，我想如果出于一些非常迷的目的（比如说 简写法），删代码真和割肉一样斟酌。。。

啊这个bug真的太艹了...

不想写了，反正别的我是不写了。写完就放假

...服了，用这样脏的修改也会有这样的结果……

做到七点半，就不修了睡大觉。 这个问题是蛮特殊的，在构造器调用里出现，恰巧我没有为赋值的情况考虑。 何况 codegen 本来就是为视图树的后序遍历情况考虑的，根本没想某些构造器还有创建窗口副作用…… 不过我突然想到一个 workaround 估计还可以

真无语了，吃饭去