|
精华帖 (3) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (6)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-12-11
最后修改：2010-12-11
半静态语言 – 背景、原理和价值
（Semi-Static Language - Background,Mechanism and Value） 【摘要】动态类型语言在企业开发和互联网开发中应用广泛，而其弱类型的内在特点使其在这些业务复杂的应用开发中存在很多缺点：无法静态验证，程序不健壮，测试成本高；缺乏静态语言如Java的实时验证、代码提示、代码重构等敏捷开发功能。为此，本文提出半静态语言，它的基本原理是两阶段模型，开发时运用变量类型声明进行类型检查，运行时采用解释执行的方式。半静态语言它结合了动态语言和静态语言的优点，同时满足灵活性、健壮性与敏捷开发的需求。 【关键词】半静态语言,动态类型语言, 静态类型语言, Velocity, Freemarker, Java 原文首发在 InfoQ China: 半静态语言 – 背景、原理和价值 PS: 第一次在InfoQ发论文，感谢凯丰热情的服务，感谢张逸、王瑜珩对论文的评审，专业认真的意见对二稿完善很有帮助。 声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
| 返回顶楼 | |
|
发表时间：2010-12-11
呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是JSP+EL， 只不过JSP不能在开发阶段像velocity那样不用转换成java代码就能解释执行， 而EL又不能静态编译成源代码。 我从去年就开始尝试做一个强类型的模板引擎， 在开发阶段能像velocity那样解释执行，也能利用ide的很多优点， 也可以静态编译成java源代码然后直接部署到生产环境，这样性能会很高。 楼主这个方案的起因是为了尽量兼容现有的velocity应用， 不过还是无法做到零成本迁移的。 已经有人在做把velocity编译成java源代码的工作了(估计2010年底能完成）， 可以带来性能提升(特别是cpu load会下降)， 也可以做到零成本迁移，唯一缺点就是在开发阶段无法利用ide的优点。 |
| 返回顶楼 | |
|
发表时间：2010-12-12
最后修改：2010-12-12
看来大家的思路和想法志同道合啊，多多交流。
ZHH2009 写道 呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是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后，开发质量和开发效率上，好处是多多的。^_^ |
| 返回顶楼 | |
|
发表时间：2010-12-12
raymond2006k 写道 看来大家的思路和想法志同道合啊，多多交流。
ZHH2009 写道 呵呵，之前有看过，其实这不是新东西，
这种“半静态语言”就像是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一样灵活的特性。 |
| 返回顶楼 | |
|
发表时间：2010-12-12
最后修改：2010-12-14
raymond2006k 写道
其实“半静态语言”乍看上去和“JSP+EL”的思路很相似，不过还是有区本质别的。对于EL，拿 JSP2.1-EL规范的例子来说：<c:out value="${customer.name}"/>， 获取model仍然是一种动态类型推断，在JSP执行前，你无法知道 name 是不是 customer 的合法属性.
1)
class Customer {
String name;
}
2) jsp声明
<%! Customer customer %>
3) el使用
${customer.name}
##$ com.abc.crm.Customer customer <HTML> Hello $customer.name </HTML>
raymond2006k 写道
不知你的强类型方案是怎样的，如果是类似 Mvel 模板的编译方式，它只是将 AST 进行了二进制化，还是一个dynamic typing system. jjw 同学谢了篇mvel 性能对比的文章，http://jjw.iteye.com/blog/706034。这种字节码方式，还是有提升空间的。 具体我们再聊聊。 你说的IDE优点指的就是我在文章中所说的 代码提示，实时验证等功能么？
context.put("customer", new Customer());
$customer.name
当在编译时生成这样的代码：
if(context.get("customer") instanceof Customer) {
Customer customer = (Customer)context.get("customer");
customer.getName();
} else {
//反射逻辑
}
|
| 返回顶楼 | |
|
发表时间：2010-12-13
好吧，希望大家早点做完，然后开源出来，再写几个例子，给javaeyer们一个交待吧:)
|
| 返回顶楼 | |
|
发表时间：2010-12-13
顶中堂，velocity的维护和重构的确是一个很头疼的问题
这么多年下来，有见过重构biz层代码的，但很少有敢重构view层展示逻辑，大量充斥着不知名的变量定义，唯一能做的的无非就是完全重写一遍 |
| 返回顶楼 | |
|
发表时间：2010-12-13
不错的文章。
在动态类型语言中这么搞有助于提高效率。 但是我的问题是这样： freemarker和velocity这样的弱类型，包括EL提供的能力，可是使得我们的程序可以超越类型（Type），比如： actionLet.submit(); 我可以不去理会actionLet具体是何种类型，只要他有这个方法就可以了。 但是如果加上一个类型申明，则意味着程序必须有类型定义，如果我们在java下开发，那么比较好的方式是定义一个接口，比如： com.xxx.web.ActionLet 这样就会导致，一些依靠约定可以完成的工作，现在不得不额外增加接口了。方案在这个方面是怎么取舍的？ |
| 返回顶楼 | |
|
发表时间：2010-12-13
又看了一遍楼主的文章，总结一下楼主引入“半静态语言”的好处：
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代码里面)去做检查， 既然已经去来源地去做检查的，其实就可以获得它的真正类型了，所以声明是多余的。 |
| 返回顶楼 | |
|
发表时间：2010-12-13
最后修改：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的原生态。 |
| 返回顶楼 | |
