从编写代码到制造代码

    软件开发作为一种工程技术，它所研究的一个重点就是如何才能有效降低软件产品的研发成本。在这一方向上，组件技术取得了空前的成功。它所提供的基本图景是像搭积木一样从无到有的组装出最终的产品。在某种意义上，这是对现代建筑工业的模仿和致敬。新材料，预制件，框架结构，这些建筑学的进展在软件领域被一一复制，建筑工地上的民工自然也成为了程序员们学习的楷模。毕竟，在组件的世界中码代码，基本上也是一种“搬砖”的行为。

    值得庆幸的是，软件开发作为一种智力活动，它天生具有一种“去民工化”的倾向。信息产品有着与物质世界产品完全不同的抽象本质。在物理空间中，建造100栋房屋，必须付出100倍的努力，老老实实的干上100遍。而在概念空间中建造100栋房屋，我们却可以说其他房屋与第一栋一模一样，加点平移旋转变换即可。一块砖填了地基就不能用来盖屋顶，而一段写好的代码却可以在任何可用的场合无损耗的被使用。一栋建好的房屋发现水管漏水要大动干戈，而在完成的软件中补个局部bug却是小菜一碟。在抽象的世界中有效的进行生产，所依赖的不应该是大干,苦干的堆砌，而应该是发现某种可用于推导的原理，基于这些原理，输入信息可以立刻转换为最终的结果，而不需要一个逐步构造的过程。即我们有可能超越组装性生产，实现某种类似于数学的原理性生产。http://canonical.iteye.com/blog/325051

    代码复用是目前软件业中鼓吹降低生产成本的主要口号之一。但是在组件技术的指向下，一般所复用的只是用于构建的砖块，而并不是某种构造原理。即使在所有信息已经确定的情况下，我们仍然不可能从需求立刻得到可执行的产品。很多代码即使我们在想象中已经历历在目，却仍然需要一行行把它们誊写下来。当我们发现系统中已经没有任何组件值得抽象的时候，仍然留下来众多的工作需要机械化的执行。代码复用的理想国距离我们仍然非常的遥远。

    子例程(subroutine)是最早的代码重用机制。这就像是将昨天已经完成的工作录制下来，在需要的时候重新播放。函数(function)相对于子例程更加强大。很多代码看起来并不一样，但是如果把其中的差异部分看作是变量，那么它们的结构就可以统一了。再加上一些判断和循环，很多面目迥异的东西其实是存在着大量共享信息的。面向对象技术是一次飞跃性的发展。众多相关信息被打包到一个名称（类型）中，复用的粒度和复杂度都大大提升。派生类从基类继承，可以通过重载实现对原有代码的细致调整。不过，这种方式仍然无法满足日益增长的复用需求。很多时候，一个名称并不足以标定我们最终需要的代码结构，在实际使用的时候还需要补充更多的信息。类型参数化，即泛型技术，从事后的角度看其实是一种明显的解决方案。根据参数动态的生成基类自然可以吸纳更多的变化。经历了所谓Modern C++的发展之后，我们现在已经非常明确，泛型并非仅仅能够实现类型共变，而是可以从类型参数中引入更丰富的结构信息，它的本质是一种代码生成的过程。http://canonical.iteye.com/blog/57244 认清了这一点，它的扩展就非常明显了

       BaseClass<ArgClass> --> CodeGenerator<DSL>

 

DSL（或者某种模型对象）相对于普通的类型(Class)，信息密度要大很多，它可以提供更丰富也更完整的输入信息。而CodeGenerator也不必拘泥于基础语言本身提供的各种编译机制，而是可以灵活应用各种文本生成技术。http://canonical.iteye.com/blog/309395 CodeGenerator在这里所提供的正是根据输入模型推导出完整实现代码的构造原理。

    现在很多人热衷于开发自己的简易代码生成工具，这些工具也许可以在简单的情形下减轻一些体力工作，但是生成的代码一般不能直接满足需求，仍然需要手工执行大量的删改工作。当代码生成之后，它成为一种固化的物质产品，不再能够随着代码生成工具的改进而同步改进，在长期的系统演化过程中，这些工具并不一定能够减少累积的工作量。

       修正过程  ==> CodeGenerator<DSL>

 

为了改进以上代码生产过程，一些人试图在CodeGenerator中引入越来越多的可配置性，将各种变化的可能内置在构造原理中。显然这会造成CodeGenerator的不正常的肿胀。当更多的偶然性被包含在原理中的时候，必然会破坏原理的简单性和普适性。

     输入信息 + 一段用于推导的原理 + 修正补充 = 真实模型

 

必须存在[修正补充]这一项才能维持以上方程的持久平衡。

    为了摆脱人工修正过程，将模型调整纳入到概念世界中，我们需要超越继承机制的，更加强大的，新的技术手段。其实在当前的技术背景下，这一技术已经是呼之欲出了。这就是AOP, Aspect Oriented Programming。http://canonical.iteye.com/blog/34941

      Biz ==[AOP extends]==> CodeGenerator<DSL> 

 

继承仅仅能够实现同名方法之间的简单覆盖，而AOP所代表的技术原理却是在代码结构空间中进行任意复杂的删改操作,它潜在的能力等价于人工调整。

    为了实现上述生产模式，需要对编程语言，组件模型，框架设计等方面进行一系列改造。目前通用的AOP实现和元编程技术其实并不足以支持以上模式。http://canonical.iteye.com/blog/275015
    这一生产模式将会如何演化，也是一个有趣的问题。按照级列理论，我们立刻可以得到如下发展方向：

   Context0 + DSL1 + EXT0 = DSL0  
   Context1 + DSL2 + EXT1 = DSL1  
   ...     

 http://canonical.iteye.com/blog/33824

Witrix平台中BizFlow可以看作是对DaoWebAction的修正模型，但是它本身具有完整的意义，可以直观的被理解。在BizFlow的基础上可以逐步建立SeqFlow，StateFlow等模型。http://canonical.iteye.com/blog/126467

      现在有些人试图深挖函数式语言，利用模式匹配之类的概念，做符号空间的全局优化。但是我们需要认识到通用的机制是很少的，能够在通用语言背景下被明确提出的问题更是很少的。只有在特定领域中，在掌握更多局部信息的情况下，我们才能提出丰富的问题，并作出一定背景下的解答。DSL的世界中待做的和可做的工作很多。http://canonical.iteye.com/blog/147065
      对于程序员而言，未来将变得越来越丰富而复杂，它将持续拷问我们的洞察力。我们不是一行行的编写代码，把需求一条条的翻译到某种实现上，而是不断发明局部的生产原理，依靠自己制定的规则在抽象的空间中不断的创造新的表象。

评论

22 楼 uda1341 2009-04-30  

night_stalker 写道

nighthawk 写道还是很欣赏canonical看待问题的视角。
我的简单理解来就是代码复用是没有问题的，路远点就远点了，得看复用到什么程度。
现在流行的框架以及你的Witrix平台不也是复用的一种体现吗。
想到个通俗的比喻：框架像是地基，他不需要我们重复劳动了，领域模型是柱子，他决定了房屋的形状。剩下的就是搬砖了。当然，搬砖砌砖也是个技术活，如果搬砖工人会点诀窍，比如AOP之类的，那会搬的更轻松。
另外，我并不看好什么CodeGenerator。那生成出来的代码与复用，是两码事。也许有CodeGenerator适合的场景，比如一些很简单通用的增删改查。但是，既然提到了简单通用，那我干吗还去用CodeGenerator，啥工具语言的上来不都是三下五除二搞定？


现有的AOP框架基本都是通过CodeGenerator实现的。
工具的本质也是代码检查器和生成器。譬如可视化编辑器定义了一个鼠标DSL，于是可以通过这个DSL产生程序代码。可是现在的工具包装得太好了，以至于人们很容易忘记它本来是什么东西……


前面我也说过，复用的第一原则是充分利用本语言的能力，其次才是CodeGenerator。
但是静态语言的缺点就是：某时候很难复用一个结构（可以是可以的，但是做出来别人看不懂），于是便衍生出各种各样的复用的通用语言——设计模式和框架。
可是回头想一想：为什么事情变得这么复杂？ 走这么远是否忘记了本来的意思？ 有时一个static if胜过千言万语。
而且，语言和框架只有语法检查的能力，逻辑检查还得靠自己，完成自己的CodeGenerator就更有意义了。


nighthawk你对代码生成的理解有误。CodeGenerator还有一个名字，叫做编译器。
http://en.wikipedia.org/wiki/Code_generation_(compiler)

在我看来，如果一个代码生成器，生成完代码就不管了，只着眼于“生成”，那绝对不能够令人满意。真正有用的代码生成器，要对所生成代码实现有效的管理，这种可管理性要体现在：
1 程序员无需接触到所生成的代码，各种修改都在代码生成器所提供的DSL语言中进行。
2 调试的时候，跟踪，断点等设置也主要在高级的DSL语言中进行，而不是一定要深入到所生成的代码内部。


在现代的各种程序语言中，有一个少有人注意的问题，那就是把声明式和命令式混淆在了一起，它们之间的关系也没有得到很好的清理。声明式是关于概念世界的，回答“是什么”的问题，而命令式是关于现实世界的，回答“如何做”的问题。

类是属于概念世界，具体的对象实例属于现实世界（内存）。类之间的关系，类与对象的关系，用声明式语言才适合，而对象具体的行动，却需要用命令式的语言表达。

只有在程序设计语言中融合声明式和命令式到一个整体框架中，才能够更符合程序员的需要。

21 楼 night_stalker 2009-03-09  

nighthawk 写道

还是很欣赏canonical看待问题的视角。
我的简单理解来就是代码复用是没有问题的，路远点就远点了，得看复用到什么程度。
现在流行的框架以及你的Witrix平台不也是复用的一种体现吗。
想到个通俗的比喻：框架像是地基，他不需要我们重复劳动了，领域模型是柱子，他决定了房屋的形状。剩下的就是搬砖了。当然，搬砖砌砖也是个技术活，如果搬砖工人会点诀窍，比如AOP之类的，那会搬的更轻松。
另外，我并不看好什么CodeGenerator。那生成出来的代码与复用，是两码事。也许有CodeGenerator适合的场景，比如一些很简单通用的增删改查。但是，既然提到了简单通用，那我干吗还去用CodeGenerator，啥工具语言的上来不都是三下五除二搞定？

现有的AOP框架基本都是通过CodeGenerator实现的。
工具的本质也是代码检查器和生成器。譬如可视化编辑器定义了一个鼠标DSL，于是可以通过这个DSL产生程序代码。可是现在的工具包装得太好了，以至于人们很容易忘记它本来是什么东西……


前面我也说过，复用的第一原则是充分利用本语言的能力，其次才是CodeGenerator。
但是静态语言的缺点就是：某时候很难复用一个结构（可以是可以的，但是做出来别人看不懂），于是便衍生出各种各样的复用的通用语言——设计模式和框架。
可是回头想一想：为什么事情变得这么复杂？ 走这么远是否忘记了本来的意思？ 有时一个static if胜过千言万语。
而且，语言和框架只有语法检查的能力，逻辑检查还得靠自己，完成自己的CodeGenerator就更有意义了。


nighthawk你对代码生成的理解有误。CodeGenerator还有一个名字，叫做编译器。
http://en.wikipedia.org/wiki/Code_generation_(compiler)

20 楼 nighthawk 2009-03-09  

还是很欣赏canonical看待问题的视角。
我的简单理解来就是代码复用是没有问题的，路远点就远点了，得看复用到什么程度。
现在流行的框架以及你的Witrix平台不也是复用的一种体现吗。
想到个通俗的比喻：框架像是地基，他不需要我们重复劳动了，领域模型是柱子，他决定了房屋的形状。剩下的就是搬砖了。当然，搬砖砌砖也是个技术活，如果搬砖工人会点诀窍，比如AOP之类的，那会搬的更轻松。
另外，我并不看好什么CodeGenerator。那生成出来的代码与复用，是两码事。也许有CodeGenerator适合的场景，比如一些很简单通用的增删改查。但是，既然提到了简单通用，那我干吗还去用CodeGenerator，啥工具语言的上来不都是三下五除二搞定？

19 楼 night_stalker 2009-03-08  

canonical 写道

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

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

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

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

A你看做一个AST就可以。

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

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

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

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

18 楼 canonical 2009-03-07  

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

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

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

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

A你看做一个AST就可以。

17 楼 night_stalker 2009-03-07  

canonical 写道

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

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

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

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

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

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

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

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

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

16 楼 canonical 2009-03-07  

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

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

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

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

15 楼 night_stalker 2009-03-07  

canonical 写道

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

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

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

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

canonical 写道

这里并不是算数运算中的+, 只是合成操作的简写。加就是加上，这个很容易理解。在我的文章中有一个更加准确的公式
  Biz =[AOP extends]=> CodeGenerator<DSL>

合成？ 你的第一个式子"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，这样也能显得很高深。

14 楼 canonical 2009-03-07  

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

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

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

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

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

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

13 楼 night_stalker 2009-03-07  

canonical 写道

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

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

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

12 楼 night_stalker 2009-03-07  

canonical 写道

不是要新建概念，而是不要仅在别人告诉我们的知识中徘徊。

假设现在我已经写好了一段代码生成器的实现，可以生成我需要的代码，例如你上面_wnd_proc的实现。 我在几个常见的应用中也用到了，可是突然有一天有一个需求，要对一个特定的msg='my_message'的时候做一个特殊处理。现在应该如何处理呢？ 是重写代码生成器，或者为代码生成器增加一个配置选项，还是利用某种AOP技术直接操作生成的代码做一点修正？

“最终的结构”和“精细的调节”不只是某种空泛的概念区别，而是对应着不同的实现策略。

“分离好生成代码和非生成代码即可”这种分离到底能做到多大的程度？是简单的代码交错，还是复杂的如同C++模板那种非常深入的编译期的递归交织。一个信息表达A到底能够以哪些方式传播到系统中的哪些部分？

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

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

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

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


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

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

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

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

11 楼 canonical 2009-03-07  

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

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

10 楼 canonical 2009-03-07  

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

9 楼 canonical 2009-03-07  

不是要新建概念，而是不要仅在别人告诉我们的知识中徘徊。

假设现在我已经写好了一段代码生成器的实现，可以生成我需要的代码，例如你上面_wnd_proc的实现。 我在几个常见的应用中也用到了，可是突然有一天有一个需求，要对一个特定的msg='my_message'的时候做一个特殊处理。现在应该如何处理呢？ 是重写代码生成器，或者为代码生成器增加一个配置选项，还是利用某种AOP技术直接操作生成的代码做一点修正？

“最终的结构”和“精细的调节”不只是某种空泛的概念区别，而是对应着不同的实现策略。

“分离好生成代码和非生成代码即可”这种分离到底能做到多大的程度？是简单的代码交错，还是复杂的如同C++模板那种非常深入的编译期的递归交织。一个信息表达A到底能够以哪些方式传播到系统中的哪些部分？

8 楼 night_stalker 2009-03-07  

canonical 写道

在我的文章里所表达的一个核心概念在于 代码生成并不必然是完整的最终的结构, 还需要通过AOP手段进行精细的调节, 而这个调节过程本身可以进一步被抽象. 无论是基础的结构,还是 AOP导入的aspect都可以进一步被分解, 用其他的DSL来描述.

我的想法是不必要在“最终的结构”和“精细的调节”上面纠结，
代码生成就是编译过程，只要分离好生成代码和非生成代码即可。

新建太多概念意义也不大。

7 楼 night_stalker 2009-03-07  

canonical 写道

我的意思不是说代码生成是AOP的一部分,我是说你提到的代码生成比AOP容易多了. 用代码生成构造结构, 用AOP手段一样可以达到而已.

"我想基于parse tree的东西已经把事情弄得很清晰了"
确实,从概念上这些东西都是非常清楚的. AOP就是一种定位组装技术,元编程就是一种代码生成. 但是概念上很清楚不代表你找到了新的应用方式. 除了别人已经做好的例子, 你能否想出什么复杂的应用实例? 如何具体应用这些概念?

举几个自己应用代码生成的例子，虽然写得不怎么样，但是觉得比用AOP容易得多

下面是一个消息处理函数的生成模版，msg_listeners通过解析其他文件得到。
（写这段函数的初衷是不需要Thunk Hack也能避免产生庞大的虚函数表）
在VC里设置了Prebuild event，每次build之前先Generate一趟（用ant，make，rake也差不多）。

一点说明：C的宏就是一种元编程，这里扩展了macro的语法，'#'开始的行除了原有的C macro之外，都被当做是ruby代码处理。这种处理方式也非常容易重用。
'${}'为嵌入相应对象的值。

#static:
LRESULT CALLBACK _wnd_proc(HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam) {
	LRESULT result = 0;
	switch(message) {
	#msg_listeners.each do |msg,listeners|
	case ${msg}:
		#listeners.each do |listener|
		if(${fname_base}.${listener})
			return result;
		#end
		break;
	#end
	//generate mouseover and leave events
	case WM_NCHITTEST:
		if(window_base::h_mouseover != hwnd) {
			SendMessage(window_base::h_mouseover, WM_MOUSELEAVE, 0, 0);
			SendMessage(hwnd, WM_MOUSEHOVER, 0, 0);
			window_base::h_mouseover = hwnd;
			return 0;
		}
		break;
	}
	//reflect unprocessed notify
	if (message == WM_NOTIFY) {
		return SendMessage(((LPNMHDR)lparam)->hwndFrom, WM_RNOTIFY, wparam, lparam);
	}
	#if child_window
	return CallWindowProc( _old_proc, hwnd, message, wparam, lparam );
	#else
	return DefWindowProc( hwnd, message, wparam, lparam );
	#end
}

下面是根据Scintilla.iface生成Ruby extension接口的Erb模版的一部分
（Scintilla的接口太多了，一个个写肯定累死人，有些细节还是不能依赖swig完成，只好自己写了）
Can AOP do this ？

<% strres_funs.each do |f| %>
static VALUE _x_<%= f[:fun] %>(<%= proto(f[:p1],f[:p2]) %>) {
	VALUE v;
	int len = _SEND(<%= f[:code] %>, <%= cval(f[:p1]) || '0' %>, 0);
	char* buf = _x_arena_alloc(len);
	_SEND(<%= f[:code] %>, <%= cval(f[:p1]) || 'len' %>, buf);
	v = rb_str_new(buf, (len>0 ? len-1 : 0));
	rb_funcall(v, id_force_encoding, 1, string_utf_8);
	return v;
}
<% end %>

动态类型，动态方法的好处是：它们都非常直观。
而AOP？什么是advice？什么是pointcut？我需要学习这些才能修改它们么？
举个例子，升级到ruby1.9，很多gem都报错：找不到"xxx".each方法。那么很简单：

class String
  alias each each_byte
end

打开类修改，定义一个别名，问题解决

可能我举的例子过于简单，但是问题没办法变得更复杂……

或者设想一个庞大的工程，需要大量补镬的场景？ 那么应用AST做点剪枝工作吧，我觉得ANTLR官网上很多文章都不错的。

这样生成也有缺点：不能改生成的目标代码。

但是，代码生成就是一个编译的过程，正如人们应该修改.java文件，而不是去修改.class文件，如果要改，就应该改源文件。

6 楼 canonical 2009-03-07  

在我的文章里所表达的一个核心概念在于 代码生成并不必然是完整的最终的结构, 还需要通过AOP手段进行精细的调节, 而这个调节过程本身可以进一步被抽象. 无论是基础的结构,还是 AOP导入的aspect都可以进一步被分解, 用其他的DSL来描述.

5 楼 canonical 2009-03-07  

我的意思不是说代码生成是AOP的一部分,我是说你提到的代码生成比AOP容易多了. 用代码生成构造结构, 用AOP手段一样可以达到而已.

"我想基于parse tree的东西已经把事情弄得很清晰了"
确实,从概念上这些东西都是非常清楚的. AOP就是一种定位组装技术,元编程就是一种代码生成. 但是概念上很清楚不代表你找到了新的应用方式. 除了别人已经做好的例子, 你能否想出什么复杂的应用实例? 如何具体应用这些概念?

4 楼 night_stalker 2009-03-07  

当我提到动态语言的时候，我所指的绝不是现有的动态语言技术实现，而只是动态语言所代表的技术概念。
但是不好意思，当我提到AOP的时候，我所指的就是像AspectXXX那样的东西……

对于你说的AOP，再次不好意思，我抽象思维能力比较弱……不是很明白为什么这么多东西都被AOP（如果我没记错，面向方面编程？）覆盖了？

现有的元编程技术已经非常强大了吧？
像boost.spirit，就可以动态添加语法规则；
动态语言实现的DSL也可以玩一个无穷序列，甚至还可以用DSL生成DSL生成DSL……
至于如何划分边界，我想基于parse tree的东西已经把事情弄得很清晰了。
如果要说谁更牛逼一点，我想可以证明它们是等价的……

3 楼 canonical 2009-03-07  

当我提到AOP的时候，我所指的决不是现有的AOP技术实现，而只是AOP所代表的技术概念。
动态语言代码生成最后所提供的效果也在AOP所涵盖的范畴之内。 AOP就是对程序代码结构的一种动态修正技术.

代码生成决不仅是代码生成工具,或者是动态脚本代码生成,或者是动态字节码代码生成,或者是JIT代码生成. 我对代码生成的关注重点在于生成的过程中如何保持概念边界,如何将它作为模型定义和转换的手段.