从编写代码到制造代码

canonical

浏览: 358597 次
性别:
来自: 北京

最近访客更多访客>>

bearyiazhi

purfan

powerrliu

goycejin

博主相关

博客

微博

相册

留言

关于我

文章分类

社区版块

存档分类

博客分类：

设计理论

制造 AOP 框架数据结构领域模型

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

值得庆幸的是，软件开发作为一种智力活动，它天生具有一种“去民工化”的倾向。信息产品有着与物质世界产品完全不同的抽象本质。在物理空间中，建造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
对于程序员而言，未来将变得越来越丰富而复杂，它将持续拷问我们的洞察力。我们不是一行行的编写代码，把需求一条条的翻译到某种实现上，而是不断发明局部的生产原理，依靠自己制定的规则在抽象的空间中不断的创造新的表象。

分享到：

类型化：形而上学的信仰 | 逆元：不存在的真实存在

2009-02-15 18:15
浏览 3014
评论(22)
论坛回复 / 浏览 (22 / 7155)
查看更多

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

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

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

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

10 楼 canonical 2009-03-07

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

9 楼 canonical 2009-03-07

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

5 楼 canonical 2009-03-07

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代码生成. 我对代码生成的关注重点在于生成的过程中如何保持概念边界,如何将它作为模型定义和转换的手段.

发表评论

您还没有登录,请您登录后再发表评论

最近访客更多访客>>

博主相关

文章分类

社区版块

存档分类

最新评论