- 浏览: 295168 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
msdn19880714:
楼主你是逗逼么,像你这样比较,直接被气死了
不小心被Cglib忽悠了(已纠正错误2009-3-1) -
javacainiaosc:
网上关于coherence的资料太少了,刚刚入手学习,感谢楼主 ...
Coherence企业级缓存(一) 特点 -
108439162:
不得不说,可能博主自己觉得这样做很牛逼了。但是你忘了依赖注入的 ...
我的开发经验分享(一)-Spring业务bean零配置 -
u010980147:
为什么不告诉我们要导入的包?你做截屏的时候顺道包impor ...
Mule web service调用中的复杂类型传递 -
bigtian:
现在办理社保转移好像没有当年这么麻烦了,国家出台了新的法律了。 ...
作为程序员看社保跨地区转移的问题
半静态语言 – 背景、原理和价值
(Semi-Static Language - Background,Mechanism and Value)
【摘要】动态类型语言在企业开发和互联网开发中应用广泛,而其弱类型的内在特点使其在这些业务复杂的应用开发中存在很多缺点:无法静态验证,程序不健壮,测试成本高;缺乏静态语言如Java的实时验证、代码提示、代码重构等敏捷开发功能。为此,本文提出半静态语言,它的基本原理是两阶段模型,开发时运用变量类型声明进行类型检查,运行时采用解释执行的方式。半静态语言它结合了动态语言和静态语言的优点,同时满足灵活性、健壮性与敏捷开发的需求。
【关键词】半静态语言,动态类型语言, 静态类型语言, Velocity, Freemarker, Java
原文首发在 InfoQ China:
半静态语言 – 背景、原理和价值
PS: 第一次在InfoQ发论文,感谢凯丰热情的服务,感谢张逸、王瑜珩对论文的评审,专业认真的意见对二稿完善很有帮助。
这个就是 半静态语言在 IDE 内最直接的优势了,实时的可视化的编译错误显示,就像 Java 一样。
但是如果整体错写(customer->custamer)成了:
这样的话,编译也能检查出来吗??
这段代码是正确的哦,因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。
如果能的话,那么我觉得:
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
基本验证规则是按 class 进行验证,这个是不多余。
如果是分析对应 Java 源文件, 这个声明可以去掉,但这是一种隐式声明, 文章中有提到的。
比如:不分析Java源码,编译器还可以内置固定变量
这是个典型的 ducking type 问题————无继承的行为多态。 ducking type是很难做到行为的强类型检查的,因此,在语义上,semi-static language 是禁止 ducking type的。
个人觉得,用什么样的语言,不管是静态强类型,或者半静态,还是动态语言,并不存在拿出来比较的价值,除非是为了做很底层的开发,或者研究用;
至于说哪个更好一点,就要根据具体的情况而定,对于模板语言而言,我个人觉得是越简单,越灵活越好,因为这意味着开发成本的降低
之前楼层的同学曾经提出过一个velocity的重构的问题,这里我也发表一下自己的看法,个人觉得,velocity其实不存在重构的问题,能够重用的东西往往都是带有极的一致性,而在网页的开发中,重用虽然能够有效的降低开发周期,但是往往是存在代价的,而且在不同项目之间的移植性往往差的要命;
另外一个关键的问题是,现有的模板引擎大部分已经是很弱的类型,甚至比脚本语言更甚;所以,我认为,如果你不是打算像google那样想要完整的搞一套控件出来,还是不要试图去对模板进行重构了,要做的只是使用已有的模板引擎把逻辑敲出来就好了...
一家之言,欢迎拍砖...
本版目前唯一的好帖。
说白了,要灵活,并且高效,这两个找个平衡点。
如何能让嵌入的半静态内容,有fp一样灵活的特性。
(Semi-Static Language - Background,Mechanism and Value)
【摘要】动态类型语言在企业开发和互联网开发中应用广泛,而其弱类型的内在特点使其在这些业务复杂的应用开发中存在很多缺点:无法静态验证,程序不健壮,测试成本高;缺乏静态语言如Java的实时验证、代码提示、代码重构等敏捷开发功能。为此,本文提出半静态语言,它的基本原理是两阶段模型,开发时运用变量类型声明进行类型检查,运行时采用解释执行的方式。半静态语言它结合了动态语言和静态语言的优点,同时满足灵活性、健壮性与敏捷开发的需求。
【关键词】半静态语言,动态类型语言, 静态类型语言, Velocity, Freemarker, Java
原文首发在 InfoQ China:
半静态语言 – 背景、原理和价值
PS: 第一次在InfoQ发论文,感谢凯丰热情的服务,感谢张逸、王瑜珩对论文的评审,专业认真的意见对二稿完善很有帮助。
评论
16 楼
sunnyfun
2010-12-14
强类型和弱类型,动态和静态没有直接的关系吧,强类型可以是动态的,弱类型也可以是静态的,只要你有精力去实现就是了。
知道basic不?最早是弱类型的,在vb里加个声明就可以变成强类型了,basic既有解释执行的,又有编译执行的
所以楼主无非是需要一个解释器和一个编译器罢了
知道basic不?最早是弱类型的,在vb里加个声明就可以变成强类型了,basic既有解释执行的,又有编译执行的
所以楼主无非是需要一个解释器和一个编译器罢了
15 楼
ustcfrank
2010-12-14
如果这样的话,那就无法解决 VelocityContext 和 Template 中变量名称不匹配的问题。
也就是说,变量名不能重构。
这个就是 半静态语言在 IDE 内最直接的优势了,实时的可视化的编译错误显示,就像 Java 一样。
但是如果整体错写(customer->custamer)成了:
这样的话,编译也能检查出来吗??
这段代码是正确的哦,因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。
如果能的话,那么我觉得:
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
基本验证规则是按 class 进行验证,这个是不多余。
如果是分析对应 Java 源文件, 这个声明可以去掉,但这是一种隐式声明, 文章中有提到的。
比如:不分析Java源码,编译器还可以内置固定变量
也就是说,变量名不能重构。
raymond2006k 写道
ustcfrank 写道
又看了一遍楼主的文章,总结一下楼主引入“半静态语言”的好处:
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
按照楼主的思路,如果
错写(name->nome)成了
那么编译阶段是能检查出来的。
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
##$ com.abc.crm.Customer customer <HTML> Hello $customer.name </HTML>
按照楼主的思路,如果
Hello $customer.name
错写(name->nome)成了
Hello $customer.nome
那么编译阶段是能检查出来的。
这个就是 半静态语言在 IDE 内最直接的优势了,实时的可视化的编译错误显示,就像 Java 一样。
引用
但是如果整体错写(customer->custamer)成了:
##$ com.abc.crm.Customer custamer <HTML> Hello $custamer.name </HTML>
这样的话,编译也能检查出来吗??
这段代码是正确的哦,因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。
引用
如果能的话,那么我觉得:
##$ com.abc.crm.Customer custamer
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
基本验证规则是按 class 进行验证,这个是不多余。
如果是分析对应 Java 源文件, 这个声明可以去掉,但这是一种隐式声明, 文章中有提到的。
比如:不分析Java源码,编译器还可以内置固定变量
<html> <body> Hello, $request.getParameter("username") ! <p/> Your logged in at $session.getAttribute("loginTime") last time. </body> </html>
14 楼
sleepinglord
2010-12-14
1.静态语言也可以解释执行。你用过单步调试?那就是在解释执行你的语句,甚至是传说中最静态的语言fortran,都是可以解释执行的!
2.动态语言也可以编译执行。你用过python,ruby?这些不能编译成exe么?甚至是传说中最动态的语言lisp,都是可以编译成exe的!
所以在解释与编译,动态与静态之间完全没有既定的规则,说谁一定要解释谁一定要编译。
类型检查,嗯……其实呢,我一直觉得,类型检查是好东东,动态也是好东东,ducking type在使用的时候也是好东东。为啥一定要矛盾呢?
我期望的语言是,你愿意写明类型,我就检查,写得越多检查越多,你不写,我就推断,推断不出来拉倒。
举例而言:我期望中的语言的函数,大概是这样的(语法可以再设计,这里只说明思路)
func(in a as const A, in b, inout c like IC, out d as D)
这里in,inout,out,as,like是关键字。
a,d写了类型const A,于是我就检查,你的参数是不是A类型的,在函数里有没有写操作?
b什么都没写,于是就不检查,运行时再报错。
like是我自己编的关键字,专门针对ducking type的情况,即,你编写一个interface,只要c长得和这个interface一样,即满足其公共方法(注意只关心公共方法),就ok!没必要从那个interface继承(有时候强制继承很没必要)。如果愿意的话,这种interface甚至只是用来做检查,不会真正参与编译。
这语言甚至可以考虑在语法上支持更多的约束的表示,以方便愿意使用的人们在编译时进行检查。
所以我觉得很多事情其实没用本质冲突的来着。
2.动态语言也可以编译执行。你用过python,ruby?这些不能编译成exe么?甚至是传说中最动态的语言lisp,都是可以编译成exe的!
所以在解释与编译,动态与静态之间完全没有既定的规则,说谁一定要解释谁一定要编译。
类型检查,嗯……其实呢,我一直觉得,类型检查是好东东,动态也是好东东,ducking type在使用的时候也是好东东。为啥一定要矛盾呢?
我期望的语言是,你愿意写明类型,我就检查,写得越多检查越多,你不写,我就推断,推断不出来拉倒。
举例而言:我期望中的语言的函数,大概是这样的(语法可以再设计,这里只说明思路)
func(in a as const A, in b, inout c like IC, out d as D)
这里in,inout,out,as,like是关键字。
a,d写了类型const A,于是我就检查,你的参数是不是A类型的,在函数里有没有写操作?
b什么都没写,于是就不检查,运行时再报错。
like是我自己编的关键字,专门针对ducking type的情况,即,你编写一个interface,只要c长得和这个interface一样,即满足其公共方法(注意只关心公共方法),就ok!没必要从那个interface继承(有时候强制继承很没必要)。如果愿意的话,这种interface甚至只是用来做检查,不会真正参与编译。
这语言甚至可以考虑在语法上支持更多的约束的表示,以方便愿意使用的人们在编译时进行检查。
所以我觉得很多事情其实没用本质冲突的来着。
13 楼
raymond2006k
2010-12-14
ustcfrank 写道
又看了一遍楼主的文章,总结一下楼主引入“半静态语言”的好处:
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
按照楼主的思路,如果
错写(name->nome)成了
那么编译阶段是能检查出来的。
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
##$ com.abc.crm.Customer customer <HTML> Hello $customer.name </HTML>
按照楼主的思路,如果
Hello $customer.name
错写(name->nome)成了
Hello $customer.nome
那么编译阶段是能检查出来的。
这个就是 半静态语言在 IDE 内最直接的优势了,实时的可视化的编译错误显示,就像 Java 一样。
引用
但是如果整体错写(customer->custamer)成了:
##$ com.abc.crm.Customer custamer <HTML> Hello $custamer.name </HTML>
这样的话,编译也能检查出来吗??
这段代码是正确的哦,因为只是variable 换了个名字 $custamer。编译器按其声明的类型进行验证。
引用
如果能的话,那么我觉得:
##$ com.abc.crm.Customer custamer
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
基本验证规则是按 class 进行验证,这个是不多余。
如果是分析对应 Java 源文件, 这个声明可以去掉,但这是一种隐式声明, 文章中有提到的。
比如:不分析Java源码,编译器还可以内置固定变量
<html> <body> Hello, $request.getParameter("username") ! <p/> Your logged in at $session.getAttribute("loginTime") last time. </body> </html>
12 楼
raymond2006k
2010-12-14
yimlin 写道
不错的文章。
在动态类型语言中这么搞有助于提高效率。
但是我的问题是这样:
freemarker和velocity这样的弱类型,包括EL提供的能力,可是使得我们的程序可以超越类型(Type),比如:
我可以不去理会actionLet具体是何种类型,只要他有这个方法就可以了。
但是如果加上一个类型申明,则意味着程序必须有类型定义,如果我们在java下开发,那么比较好的方式是定义一个接口,比如:
这样就会导致,一些依靠约定可以完成的工作,现在不得不额外增加接口了。方案在这个方面是怎么取舍的?
在动态类型语言中这么搞有助于提高效率。
但是我的问题是这样:
freemarker和velocity这样的弱类型,包括EL提供的能力,可是使得我们的程序可以超越类型(Type),比如:
actionLet.submit();
我可以不去理会actionLet具体是何种类型,只要他有这个方法就可以了。
但是如果加上一个类型申明,则意味着程序必须有类型定义,如果我们在java下开发,那么比较好的方式是定义一个接口,比如:
com.xxx.web.ActionLet
这样就会导致,一些依靠约定可以完成的工作,现在不得不额外增加接口了。方案在这个方面是怎么取舍的?
这是个典型的 ducking type 问题————无继承的行为多态。 ducking type是很难做到行为的强类型检查的,因此,在语义上,semi-static language 是禁止 ducking type的。
11 楼
deepthink
2010-12-13
个人觉得,用什么样的语言,不管是静态强类型,或者半静态,还是动态语言,并不存在拿出来比较的价值,除非是为了做很底层的开发,或者研究用;
至于说哪个更好一点,就要根据具体的情况而定,对于模板语言而言,我个人觉得是越简单,越灵活越好,因为这意味着开发成本的降低
之前楼层的同学曾经提出过一个velocity的重构的问题,这里我也发表一下自己的看法,个人觉得,velocity其实不存在重构的问题,能够重用的东西往往都是带有极的一致性,而在网页的开发中,重用虽然能够有效的降低开发周期,但是往往是存在代价的,而且在不同项目之间的移植性往往差的要命;
另外一个关键的问题是,现有的模板引擎大部分已经是很弱的类型,甚至比脚本语言更甚;所以,我认为,如果你不是打算像google那样想要完整的搞一套控件出来,还是不要试图去对模板进行重构了,要做的只是使用已有的模板引擎把逻辑敲出来就好了...
一家之言,欢迎拍砖...
10 楼
hatedance
2010-12-13
静态类型语言也可以被解释执行,动态类型语言也可以编译执行。
所以,jsp就可以满足lz的要求,在eclipse里支持类型检查和代码提示,修改完了tomcat直接后台编译运行,无须用户干预。
至于velocity,我觉得关键也是要做一个eclipse插件支持类型检查等功能。
所以,jsp就可以满足lz的要求,在eclipse里支持类型检查和代码提示,修改完了tomcat直接后台编译运行,无须用户干预。
至于velocity,我觉得关键也是要做一个eclipse插件支持类型检查等功能。
9 楼
allbin1983
2010-12-13
在展示层原生态HTML也是一个思路,比如: http://simpleframework.net/simple/main/doc/d2/d.jsp?a=2.1.3 的想法也不错。
比如开发一个树,对应的demo.jsp 如下,只需要通过id="demoDbTree"就可以完成数据的绑定,不需要学更多的语法:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<div style="padding: 10px;">
<div>这棵树直接和后台数据库的表绑定</div>
<div id="demoDbTree" style="padding: 8px; border: 5px solid #ddd;"></div>
</div>
对应的 demo.xml 描述文件:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="/xsd/default/simple.xsd">
<components>
<dbTree name="demoDbTree" containerId="demoDbTree" tableName="simple_department"
parentIdName="parentId" idName="id" textName="text" width="300">
</dbTree>
</components>
</page>
实现原理:
Web应用中,无论服务器端采用(Java EE或.Net),客户端的请求(Request)经Web或应用服务器解析后,最终返回客户端的响应(Response)内容主体都是HTML(含Javascript脚本、CSS等)。由此,就提供了解决问题的契机,那就是在响应内容返回客户端(/浏览器)之前,“拦截”响应,解析响应HTML,并进行“再处理”,由此,可以保留HTML和HTTP的原生态。
比如开发一个树,对应的demo.jsp 如下,只需要通过id="demoDbTree"就可以完成数据的绑定,不需要学更多的语法:
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<div style="padding: 10px;">
<div>这棵树直接和后台数据库的表绑定</div>
<div id="demoDbTree" style="padding: 8px; border: 5px solid #ddd;"></div>
</div>
对应的 demo.xml 描述文件:
<?xml version="1.0" encoding="UTF-8"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="/xsd/default/simple.xsd">
<components>
<dbTree name="demoDbTree" containerId="demoDbTree" tableName="simple_department"
parentIdName="parentId" idName="id" textName="text" width="300">
</dbTree>
</components>
</page>
实现原理:
Web应用中,无论服务器端采用(Java EE或.Net),客户端的请求(Request)经Web或应用服务器解析后,最终返回客户端的响应(Response)内容主体都是HTML(含Javascript脚本、CSS等)。由此,就提供了解决问题的契机,那就是在响应内容返回客户端(/浏览器)之前,“拦截”响应,解析响应HTML,并进行“再处理”,由此,可以保留HTML和HTTP的原生态。
8 楼
ustcfrank
2010-12-13
又看了一遍楼主的文章,总结一下楼主引入“半静态语言”的好处:
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
按照楼主的思路,如果
错写(name->nome)成了
那么编译阶段是能检查出来的。
但是如果整体错写(customer->custamer)成了:
这样的话,编译也能检查出来吗??
如果能的话,那么我觉得:
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
1、可以重构
2、提高开发效率:比如在IDE中能“.”出属性。
这里我说说重构,拿这段段代码来讲:
##$ com.abc.crm.Customer customer <HTML> Hello $customer.name </HTML>
按照楼主的思路,如果
Hello $customer.name
错写(name->nome)成了
Hello $customer.nome
那么编译阶段是能检查出来的。
但是如果整体错写(customer->custamer)成了:
##$ com.abc.crm.Customer custamer <HTML> Hello $custamer.name </HTML>
这样的话,编译也能检查出来吗??
如果能的话,那么我觉得:
##$ com.abc.crm.Customer custamer
这个声明就是多余的。
原因:说明你的检查过程一定要去customer对象真的来源地(很可能是java代码里面)去做检查,
既然已经去来源地去做检查的,其实就可以获得它的真正类型了,所以声明是多余的。
7 楼
yimlin
2010-12-13
不错的文章。
在动态类型语言中这么搞有助于提高效率。
但是我的问题是这样:
freemarker和velocity这样的弱类型,包括EL提供的能力,可是使得我们的程序可以超越类型(Type),比如:
我可以不去理会actionLet具体是何种类型,只要他有这个方法就可以了。
但是如果加上一个类型申明,则意味着程序必须有类型定义,如果我们在java下开发,那么比较好的方式是定义一个接口,比如:
这样就会导致,一些依靠约定可以完成的工作,现在不得不额外增加接口了。方案在这个方面是怎么取舍的?
在动态类型语言中这么搞有助于提高效率。
但是我的问题是这样:
freemarker和velocity这样的弱类型,包括EL提供的能力,可是使得我们的程序可以超越类型(Type),比如:
actionLet.submit();
我可以不去理会actionLet具体是何种类型,只要他有这个方法就可以了。
但是如果加上一个类型申明,则意味着程序必须有类型定义,如果我们在java下开发,那么比较好的方式是定义一个接口,比如:
com.xxx.web.ActionLet
这样就会导致,一些依靠约定可以完成的工作,现在不得不额外增加接口了。方案在这个方面是怎么取舍的?
6 楼
agapple
2010-12-13
顶中堂,velocity的维护和重构的确是一个很头疼的问题
这么多年下来,有见过重构biz层代码的,但很少有敢重构view层展示逻辑,大量充斥着不知名的变量定义,唯一能做的的无非就是完全重写一遍
这么多年下来,有见过重构biz层代码的,但很少有敢重构view层展示逻辑,大量充斥着不知名的变量定义,唯一能做的的无非就是完全重写一遍
5 楼
ustcfrank
2010-12-13
好吧,希望大家早点做完,然后开源出来,再写几个例子,给javaeyer们一个交待吧:)
4 楼
ZHH2009
2010-12-12
<div class="quote_title">raymond2006k 写道</div>
<div class="quote_div">
<br>其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.<br>
</div>
<p><br><br>这个没错,EL和velocity的核心实现都是一样的,<br>都是先用JavaCC把文法文件转换成Parser和TokenManager,<br>然后Parser和TokenManager在运行时把模板解析为一棵抽象语法树(AST),<br>最后再从上往下遍历这棵树,树结点有很多类型(比如Reference、Method、MathNode等等),<br>对这些树结点"求值",最后把结果放入一个Writer中。<br><br>为什么说“半静态语言”乍看上去和“JSP+EL”的思路很相似呢?<br>比如举个例子:</p>
<pre name="code" class="java">1)
class Customer {
String name;
}
2) jsp声明
<%! Customer customer %>
3) el使用
${customer.name}
</pre>
<p><br><br>如果把2)和3)放到一个foo.jsp文件中,是不是就很像下面这段代码呢:</p>
<pre name="code" class="java">##$ com.abc.crm.Customer customer
<HTML>
Hello $customer.name
</HTML>
</pre>
<p><br><br>只不过这里对customer这个变量的赋值不在当前模板(或jsp)中进行,而是放在控制器层或其他地方赋值,<br>这会给人一种不一致的感觉(比如大家养成的习惯是变量在使用前不能为null),<br>这里的变量声明仅仅是个"类型暗示",不是一般程序语言中的变量声明。<br><br>当然,上面给出的“JSP+EL”的代码是不能工作的,<br>jsp之所以做不到像velocity那样能解释执行,主要是因为jsp中有可能包含java源代码(更规范的说法叫: "scriptlet"),<br>如果把这个限制去掉,就很容易做到像velocity那样解释执行了。</p>
<div class="quote_title">raymond2006k 写道</div>
<div class="quote_div">
<br>不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。 <br>具体我们再聊聊。 <br>你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么? <br>
</div>
<p><br><br>我所说的"强类型的模板引擎",就是把jsp中的"scriptlet"去掉,<br>如果应用想要使用for\while这样的功能,可以从velocity、freemarker借鉴一下,都是有现成的解决方案的。<br><br>如果有了类型声明,IDE可以做很多事了,比如输入一个点号就能提示你有哪些字段和方法可用,按下F3就会跳到声明的地方。<br><br>静态编译(包括现在做的velocity编译)也像jsp的传统做法,先将模板转成java源代码,最后再用编译器编译成字节码,<br>当然也可以直接用ASM不经过编译器直接把模板转成字节码,这种方式缺点是难度大,不方便开发调试。<br><br>关于性能提升这块,因为velocity本身的渲染性能就很高,所以编译后的字节码就目前来看要做到两倍提升会有点难度,<br>主要还是cpu这块要好很多,具体的测试报告还是内部邮件的方式,不方便发出来。<br><br>PS1. 上面提到的mvel 性能对比的文章还是没做到极致,<br>请参见这里:<br><a href="http://rdc.taobao.com/team/jm/archives/552">大方法的执行性能与调优过程小记</a><br><br><br>我们现在的做法是尽量避免反射调用,做到类似jit的功能,考虑到数据一旦放到Context中就很少变动了,<br>此时可以根据数据类型来生成代码:<br><br>比如先把数据放到Context:</p>
<pre name="code" class="java">context.put("customer", new Customer());
$customer.name
当在编译时生成这样的代码:
if(context.get("customer") instanceof Customer) {
Customer customer = (Customer)context.get("customer");
customer.getName();
} else {
//反射逻辑
}
</pre>
<p> </p>
<p> </p>
<p> </p>
<div class="quote_div">
<br>其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.<br>
</div>
<p><br><br>这个没错,EL和velocity的核心实现都是一样的,<br>都是先用JavaCC把文法文件转换成Parser和TokenManager,<br>然后Parser和TokenManager在运行时把模板解析为一棵抽象语法树(AST),<br>最后再从上往下遍历这棵树,树结点有很多类型(比如Reference、Method、MathNode等等),<br>对这些树结点"求值",最后把结果放入一个Writer中。<br><br>为什么说“半静态语言”乍看上去和“JSP+EL”的思路很相似呢?<br>比如举个例子:</p>
<pre name="code" class="java">1)
class Customer {
String name;
}
2) jsp声明
<%! Customer customer %>
3) el使用
${customer.name}
</pre>
<p><br><br>如果把2)和3)放到一个foo.jsp文件中,是不是就很像下面这段代码呢:</p>
<pre name="code" class="java">##$ com.abc.crm.Customer customer
<HTML>
Hello $customer.name
</HTML>
</pre>
<p><br><br>只不过这里对customer这个变量的赋值不在当前模板(或jsp)中进行,而是放在控制器层或其他地方赋值,<br>这会给人一种不一致的感觉(比如大家养成的习惯是变量在使用前不能为null),<br>这里的变量声明仅仅是个"类型暗示",不是一般程序语言中的变量声明。<br><br>当然,上面给出的“JSP+EL”的代码是不能工作的,<br>jsp之所以做不到像velocity那样能解释执行,主要是因为jsp中有可能包含java源代码(更规范的说法叫: "scriptlet"),<br>如果把这个限制去掉,就很容易做到像velocity那样解释执行了。</p>
<div class="quote_title">raymond2006k 写道</div>
<div class="quote_div">
<br>不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。 <br>具体我们再聊聊。 <br>你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么? <br>
</div>
<p><br><br>我所说的"强类型的模板引擎",就是把jsp中的"scriptlet"去掉,<br>如果应用想要使用for\while这样的功能,可以从velocity、freemarker借鉴一下,都是有现成的解决方案的。<br><br>如果有了类型声明,IDE可以做很多事了,比如输入一个点号就能提示你有哪些字段和方法可用,按下F3就会跳到声明的地方。<br><br>静态编译(包括现在做的velocity编译)也像jsp的传统做法,先将模板转成java源代码,最后再用编译器编译成字节码,<br>当然也可以直接用ASM不经过编译器直接把模板转成字节码,这种方式缺点是难度大,不方便开发调试。<br><br>关于性能提升这块,因为velocity本身的渲染性能就很高,所以编译后的字节码就目前来看要做到两倍提升会有点难度,<br>主要还是cpu这块要好很多,具体的测试报告还是内部邮件的方式,不方便发出来。<br><br>PS1. 上面提到的mvel 性能对比的文章还是没做到极致,<br>请参见这里:<br><a href="http://rdc.taobao.com/team/jm/archives/552">大方法的执行性能与调优过程小记</a><br><br><br>我们现在的做法是尽量避免反射调用,做到类似jit的功能,考虑到数据一旦放到Context中就很少变动了,<br>此时可以根据数据类型来生成代码:<br><br>比如先把数据放到Context:</p>
<pre name="code" class="java">context.put("customer", new Customer());
$customer.name
当在编译时生成这样的代码:
if(context.get("customer") instanceof Customer) {
Customer customer = (Customer)context.get("customer");
customer.getName();
} else {
//反射逻辑
}
</pre>
<p> </p>
<p> </p>
<p> </p>
3 楼
androidleader
2010-12-12
raymond2006k 写道
看来大家的思路和想法志同道合啊,多多交流。
其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么?
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity,但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术,尽量接近 零迁移成本。因为,根据我们的分析,完全零成本是很有难度的。可以适当安排进行Code Refactor,辅以少量显式声明,毕竟,实现半静态化Velocity后,开发质量和开发效率上,好处是多多的。^_^
ZHH2009 写道
呵呵,之前有看过,其实这不是新东西,
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.
ZHH2009 写道
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么?
ZHH2009 写道
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity,但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术,尽量接近 零迁移成本。因为,根据我们的分析,完全零成本是很有难度的。可以适当安排进行Code Refactor,辅以少量显式声明,毕竟,实现半静态化Velocity后,开发质量和开发效率上,好处是多多的。^_^
本版目前唯一的好帖。
说白了,要灵活,并且高效,这两个找个平衡点。
如何能让嵌入的半静态内容,有fp一样灵活的特性。
2 楼
raymond2006k
2010-12-12
看来大家的思路和想法志同道合啊,多多交流。
其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么?
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity,但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术,尽量接近 零迁移成本。因为,根据我们的分析,完全零成本是很有难度的。可以适当安排进行Code Refactor,辅以少量显式声明,毕竟,实现半静态化Velocity后,开发质量和开发效率上,好处是多多的。^_^
ZHH2009 写道
呵呵,之前有看过,其实这不是新东西,
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
其实“半静态语言”乍看上去和“JSP+EL”的思路很相似,不过还是有区本质别的。对于EL,拿 JSP2.1-EL规范的例子来说:<c:out value="${customer.name}"/>, 获取model仍然是一种动态类型推断,在JSP执行前,你无法知道 name 是不是 customer 的合法属性.
ZHH2009 写道
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
不知你的强类型方案是怎样的,如果是类似 Mvel 模板的编译方式,它只是将 AST 进行了二进制化,还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章,http://jjw.iteye.com/blog/706034。这种字节码方式,还是有提升空间的。
具体我们再聊聊。
你说的IDE优点指的就是我在文章中所说的 代码提示,实时验证等功能么?
ZHH2009 写道
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
虽然通过comment指令扩展可以和现有Velocity引擎做到run time compatiblity,但毕竟增加了变量声明语法。 对新开发应用没什么问题。 老应用我们根据实际情况采用 隐式声明技术,尽量接近 零迁移成本。因为,根据我们的分析,完全零成本是很有难度的。可以适当安排进行Code Refactor,辅以少量显式声明,毕竟,实现半静态化Velocity后,开发质量和开发效率上,好处是多多的。^_^
1 楼
ZHH2009
2010-12-11
呵呵,之前有看过,其实这不是新东西,
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
这种“半静态语言”就像是JSP+EL,
只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行,
而EL又不能静态编译成源代码。
我从去年就开始尝试做一个强类型的模板引擎,
在开发阶段能像velocity那样解释执行,也能利用ide的很多优点,
也可以静态编译成java源代码然后直接部署到生产环境,这样性能会很高。
楼主这个方案的起因是为了尽量兼容现有的velocity应用,
不过还是无法做到零成本迁移的。
已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成),
可以带来性能提升(特别是cpu load会下降),
也可以做到零成本迁移,唯一缺点就是在开发阶段无法利用ide的优点。
发表评论
-
Velocity常见问题
2011-02-09 11:31 01. foreach循环里set临 时变量碰到null的问题 ... -
Web安全纪要
2011-01-25 17:05 01.HttpOnly Using Java to Set H ... -
Eclipse 插件开发技巧
2010-12-19 13:42 01. 菜单和toolbar <action ... -
Xml 的两类应用场景
2010-11-16 09:24 2331Xml 有两类应用场景 1 解析配置文件 这类场景侧重满 ... -
对敏捷的一点看法
2010-10-22 10:50 152410月14日敏捷中国2010 ... -
Apache项目提交流程
2010-08-21 09:47 0要将自己的项目提交给A ... -
Java应用性能问题技巧
2010-07-28 14:38 01. XML 解析时,会到 jar/META-INF/ 下去找 ... -
maven archetype 创建
2010-07-15 09:40 01. 创建一个 archetype 项目 mvn arche ... -
ConcurrentTest并发测试框架介绍
2010-07-10 23:58 1919ConcurrentTest Sourceforge Li ... -
使用Eclipse WTP进行快速Web开发(3)- 开发演示
2010-06-09 13:08 6393使用Eclipse WTP进行快速Web开发(3) 在前 ... -
使用Eclipse WTP进行快速Web开发(2)-准备演示项目
2010-06-08 18:19 4262目前,很多项目基于 maven 进行开发,构建和发布。 而 ... -
使用Eclipse WTP进行快速Web开发(1) - 配置Tomcat
2010-06-08 18:18 8667使用Eclipse WTP进行快速We ... -
使用Eclipse WTP进行快速Web开发
2010-06-08 17:38 0使用Eclipse WTP进行快速Web开发 -
WebBeans 规范适合我们吗?
2010-02-28 21:23 1544JavaEE6 规范已经正式获得通过了,其中一个亮点就是 ... -
认识WebBean ---- 定义
2010-02-16 13:07 3712Gavin King在开发 Seam ... -
YY一下今年技术上想做的事情
2010-01-30 14:15 2902去年下半年除了基 ... -
Java同步锁一个技巧
2010-01-30 11:02 4770Synchronized 同步 Java5开始虽然引入了高 ... -
key-value 型数据库
2010-01-03 22:54 0key-value 型数据库 Tokyo Tyrant Li ... -
HSql的schema
2010-01-03 16:33 1380前段时间被HSql的Schema问题搞的头大。今天梳理一下 ... -
Bean copy性能对比
2009-10-18 00:43 0thread = 1, repeat = 100 TimedT ...
相关推荐
《InfoQ架构师2016合集》是面向IT专业人士,尤其是架构师群体的一份珍贵资源,集合了2016年InfoQ平台上的众多精彩文章和讨论,旨在分享和探讨当时的最新技术和最佳实践。InfoQ作为一个全球知名的IT资讯网站,其内容...
标题“infoq_topic”可能指的是一个InfoQ技术网站上的专题讨论,这通常涵盖某一特定的IT主题或技术。InfoQ是一个知名的在线平台,提供最新的软件开发资讯、深度文章、会议报道和技术访谈等内容。由于描述是“NULL”...
《infoQ架构师月刊上部》集合了2008年至2012...以上只是《infoQ架构师月刊上部》可能包含的部分知识点,每一篇文章都可能深入探讨了这些主题,提供了丰富的实践案例和专家见解,对提升架构师的专业素养具有极大的价值。
InfoQ架构师月刊是一份专注于技术架构师的月刊,它关注于最新的技术动态和深度的技术文章。这份月刊可能涵盖了各种编程语言的最新版本、大数据技术、以及AI技术等多个领域。在所提供的内容中,我们可以看到月刊提到...
【InfoQ:软件工程数智化研究报告-可观测应用篇2023】这份报告深入探讨了在云原生技术、敏捷开发和DevOps理念推动下,软件工程领域的新趋势——可观测性。随着企业对业务灵活性和客户体验的重视,系统稳定性与可靠性...
InfoQ云生态期刊是一系列深度探讨云计算领域动态、技术趋势和实践案例的专业出版物。这套期刊涵盖了从第一期到第八期的完整内容,为读者提供了丰富的云计算知识库。InfoQ作为一个知名的IT信息与社区平台,其发布的云...
《infoQ架构师月刊下部》集合了2013年至2017年8月期间在infoQ平台上发布的关于架构领域的深度文章和专题,是广大架构师和IT从业者学习、研究架构技术的重要资源。infoQ作为一个全球知名的IT技术交流平台,其内容覆盖...
infoq 架构师8月刊 infoq 架构师8月刊 infoq 架构师8月刊
InfoQ作为一个知名的IT资讯平台,一直致力于分享高质量的技术信息和实践经验,帮助开发者和架构师们保持对行业动态的敏锐洞察。 在《Architect-200907-by-InfoQ.pdf》这期电子杂志中,我们可以预见到涵盖了以下几个...
OSGi(Open Services Gateway Initiative)是一种开放的模块化系统架构,用于创建动态、可扩展的应用程序和服务。这个框架的核心理念是将复杂的软件系统分解为独立的、可重用的组件,称为服务或模块。InfoQ的"OSGi...
infoq 架构师 2019年月刊收集 infoq 架构师 2019年月刊收集
他证明了美学和技术可以完美融合,设计中的极致追求具有巨大的价值,并且不断创造可以深刻改变人类生活。 #### 二、争渡读屏杨永全谈网页无障碍设计与体验 - **背景**:无障碍设计旨在确保所有人都能方便地访问...
ArchSummit北京2019大会演讲 PPT 分共三个压缩包 2019年InfoQ架构师峰会ppt.z01 2019年InfoQ架构师峰会ppt.z02 2019年InfoQ架构师峰会ppt.zip
- **深度参与和技术洞察**:无论是翻译国外的技术文章还是本地化的技术报道,InfoQ中文站的编辑都能够凭借其深厚的技术积累和行业洞察力,为读者带来有价值的见解和启示。这种深度参与不仅有助于提升内容的质量,还...
通过对2012年11月的INFOQ架构师期刊的分析,我们可以看到云计算、企业安全、企业架构以及最新的技术趋势等方面的重要内容。这些文章不仅提供了实用的技术指导,也为读者带来了对未来技术发展方向的思考。无论是对于...
InfoQ中文站在不到两年半的时间内迅速崛起,获得了全球中高端技术人员的认可,其成功的关键在于专注于企业软件开发领域,避免了内容的过度泛化。这种专注性使得InfoQ能够在特定领域内提供深度和高质量的信息,从而...
《InfoQ_ArchSummit全球架构师峰会_Day1_rebuilt》是InfoQ组织的一场专注于架构设计和技术领导力的盛会。这场会议汇集了全球顶尖的架构师、技术领导者和行业专家,共同探讨和分享了关于软件架构设计的最新趋势、最佳...
InfoQ是一个知名的IT技术信息分享平台,涵盖了各种编程语言、框架、工具和技术趋势的最新资讯。通过这个爬虫,我们可以自动抓取并分析InfoQ网站上的文章,获取有价值的技术信息。 【描述】"基于aiohttp的infoq技术...