前几天gfh在QQ群里介绍了一下MS的两项最新技术（应该还算是未来技术吧）： G# 和 Cω，令狐就前者说了一下他对AOP的看法。我今天也来说说我的看法吧。
不可否认，G#对AOP的实现是很强的，比如原文中那个例子是对既有代码的编译时织入。这也就意味着它可以在不改变原有代码的前提下进行AOP切入。而且据说它还可以支持运行时织入，应该说是一种相当理想的AOP实现。它解决了目前主流AOP技术实现的很多问题。
比如像AspectJ这样的编译时织入，需要使用特定的语法。而Nanning这样的动态织入又是依赖动态代理的，并且也有一套规范。远不及G#这样简单优美。
再
说Cω，它相当于一种内置了O/R
Mapping的语言。它提供了对数据库访问的编译时检查，就像我前两个月在DELPHI下做的那个数据据集代理类的其中一个目的是一样的。但是我那个是
一个很粗糙的东西，依赖于代码生成，而且还是手工生成。而目前的很多O/R
Mapping则是通过工具生成。但Cω做得更多，它在语言层面就提供了这样的能力，它会在编译时通过ADO.net从数据库里自动生成（这部分是我从原
文中的例子里猜测的），这使得它的使用会简单很多。
还有就是Cω提供了对XML的自动绑定，它也是相当于在语言层面实现了我以前用的XML Data binding技术，也就是说直接把XML当成class来用。这也是我一直向往了很久的一项功能。
但
是有必要为了一项功能就发明一个语言吗？更何况这两种语言的设计思路都是不可移植的。G#依赖于.net运行环境和IL编译器（后编译织入必须修改编译器
的规范才有可能），而Cω则除了这些以外，还需要依赖ADO.net（并且这相ADO.net也需要是支持特定功能的版本）。
诱惑很大，风险也很大。----因为就目前来说我们只看到它们所展示出来的优点，投入实际应用后将面临着什么样的问题，我们还一无所知。
GIGIX昨天也谈了一下Cω。他认为Cω的强类型声明使它的语法相当难看，他倾向于支持Groovy之类的脚本语言，这点我有同感。
为
了一些稍强的功能特地“创造”出一门新的语言，不如改用更为强大的脚本语言或动态语言。和脚本语言/动态语言相比，G# 和 Cω
无非是可以在编译时提供那些功能，因此可能带来少量的性能提升，但是付出的代价将是局限和风险，特别是在虚拟机平台下，这种性能提升将会是比较有限的。
