从编写代码到制造代码

AOP在技术上仅仅意味着对代码结构的一种动态调整能力而已。它当然可以做任何事情。因为它在原则上可以增加任何函数，可以删除任何函数，可以修改任何函数的实现。当然目前的具体的AOP实现是无法做到以上部分的。目前的AOP实现不方便不意味着它本身的概念能力差， 现在的实现有问题正是我们需要做工作的地方。

假设 A = G(a),  我们根据信息a可以生成最后的结构 A, 通过AOP可以采用更加灵活的策略

A = O + ( A - O)   = O + Aspect , 这里O可以是任何结构。 Aspect仅仅是说相对于基础结构它是一个补充而已。 Aspect本身当然可以用代码生成技术等进行构造。 对于构造最终我们需要的A而言，直接用代码生成或者是使用AOP构造， 或者是代码生成结合AOP, 它们的能力都是一样的， 只是不同的策略的灵活程度，方便程度不一样而已。

第一个问题：这就体现了代码生成器用动态语言实现的好处。

如果要做一个特殊处理，做一些项目特定的微调时，不需要重写生成器，也不需要重新配置（本来这个东西就是0配置……），动态语言的元编程能力提供了强大的灵活性。

方案A：msg_listeners是分析其他文档产生的，listener函数体也在分析数据中，迭代修改msg='my_message'函数体即可（甚至连动态性都没用上……）。

方案B：修改这个模版，增加一个if(${msg}==my_message)，由于编译期两者都是常量，自动被优化掉。


第二个问题：依实际情况而定了。

而且AOP也不能保证你修改了生成的代码之后不出任何问题吧。

你问的问题很好，虽然我没有这样的疑惑……我所有给编译器的源文件都是生成的……也没遇到过要改那些东西的需求。

最后，由于只对#做了手脚，代码编辑器还是认账的。

问一个问题： O是任何结构？ 你这里的+是什么？ 证明了+运算的交换律没？

"第一个问题：这就体现了代码生成器用动态语言实现的好处"。 这个没看出你所谓的动态语言实现的好处在哪里。 如果动态语言实现的时候没有考虑到某个扩展，你能够在不修改任何生成器代码的情况下实现这个扩展吗？

你的回答其实都是要修改原先生成器本身的代码的，这是对原有抽象的破坏。

AOP是必要的一种技术，这一点对大多数人来说都是意识不到的。因为对大多数人来说，AOP只是偶尔使用的调剂，代码生成代码也只是系统中可有可无的部分。但是对于我们而言，代码生成是系统运行的核心，绝大多数代码都是基于生成概念的情况下，对于AOP概念的依赖就成为必然了。

“而且AOP也不能保证你修改了生成的代码之后不出任何问题吧”。AOP当然无法保证，而且事实上因为AOP技术的强大能力伴随着对系统结构的巨大破坏性，因此我们必须发展一系列的技术来规范，限制AOP的处理方式。这个其实是需要做工作的地方。

现在很多利用模板语言进行的代码生成是没有任何规范约束的，而C++和D语言中的元编程则是在严格的规范中进行的。

“问一个问题： O是任何结构？ 你这里的+是什么？ 证明了+运算的交换律没？ ”。 这里并不是算数运算中的+, 只是合成操作的简写。加就是加上，这个很容易理解。在我的文章中有一个更加准确的公式
  Biz =[AOP extends]=> CodeGenerator<DSL>

那要看你对生成器的定义范畴了，我觉得Template只是源代码的一部分，并不是生成器的一部分，输入数据更加是源代码的一部分了。

而且照你这么说，AOP也是生成器代码了。

当我们还在思考这是不是破坏了某抽象的时候，别人的伟大产品已经出炉了。



合成？ 你的第一个式子"A=O+(A-O)" 问题就出来了：
如果A定义了一个函数f，A-O删除了f，那么g(f)是改成g(0)还是直接删掉呢？
假设改成g(0)，那O+(A-O)是否要把所有0替换成f呢？
假设删掉，那么O+(A-O)如何知道要在哪个位置补上g(f)呢？

接着第二个式子，看了好一会才明白……这些符号是你自创的还是借用的？
AOP*CodeGenerator， 结果不还是CodeGenerator？
如果要给CodeGenerator分层次，我还可以定义一个级数，每次CG都更接近Biz，这样也能显得很高深。

"Template只是源代码的一部分". 如果template本身已经写得非常复杂了，不需要抽象吗， 不需要重用吗。你怎么重用template?

Aspect本身当然也是可以由生成器生成的。

A不是函数，它是一个具体的程序结构。我们的工作本身就是这样实现，不是什么理论问题。加是一个非常复杂的操作，具体是哪个位置当然是有一系列规则确定的。

"结果不还是CodeGenerator". 这个怎么是呢？ 其中有手写的部分，有生成的部分。 有重用的通用的部分， 有特殊的针对特定应用的部分。它们之间是以复杂的方式合成的。不是显得高深，而是你是否能够真正的为这些概念找到实际的应用。

请给一个应用的例子，大家都明白的那种。

老实说我不明白template犯了什么错，我就不能改它吗？ 非要AOP它吗？ 我就不能用对待别的源代码相同的方式对待它吗？ 源代码就不能抽象重用吗？

"加是个非常复杂的操作"……你刚才还说"加就是加上"……不吐你槽了

如果你把CodeGenerator的外延定得这么宽，整个程序都是CodeGenerator了，手工copy也是CodeGenerator了……

如果你说这个A是个AST或者字符串或者一群蚂蚁，我明白。你说“一个具体的程序结构”，我就搞不懂你要表达的意思了。

其实你好像没有去看我写的文章。具体的东西我已经写了不少了。

加在概念上是简单的加，非常直白。但是具体操作的时候，要找到合适的地方，具体加的时候要做的操作就需要有复杂的实现约束了。这个很难理解了吗。因为从概念上说，我手里有现成的一些代码，现在有一些增量修改，它们放在一起要合成最终我们需要的代码，这个不是很简单的吗，但是你能很简单的定义出规则来实现这个过程吗。

template可以改，没有问题啊。这说明你没有AOP的需要。而我们在大规模使用代码生成技术的时候就不能一句“非要AOP它吗”就可以解决问题的了。这就如同说所有的开发不都是写代码吗，我要抽象干吗呢。源代码当然是要重用抽象，有了AOP你才能做到更好的重用，这个很难理解吗。

手工copy当然不是CodeGenerator了。 你为什么会有这种误解呢。CodeGenerator在我的文章中外延并不大啊， 用某种技术生成的才是generate的，直接用原生语言手写的当然不是了。

A你看做一个AST就可以。

抽象重用的第一考虑应该是充分利用本语言的结构，然后才是代码生成，我玩玩动态语言生成就满足了，的确没有AOP的需要 。

btw：Template是我手写的，不是生成的。

老实说你写的东西码那么长字，看不下去……好意心领了。

不要怒啊，一定会有理解你支持你的人的。