有必要把什么都加到语言里吗?--谈谈 G# 和 Cω

前几天gfh在里介绍了一下MS的两项最新技术(应该还算是未来技术吧): G#,令狐就前者说了一下他对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ω 无非是可以在编译时提供那些功能,因此可能带来少量的性能提升,但是付出的代价将是局限和风险,特别是在虚拟机平台下,这种性能提升将会是比较有限的。

你可能感兴趣的:(语言)