seo做的比较好的网站,顺德大良网站建设,网站换了服务器,网站开发的标准http://blog.csdn.net/aimingoo/archive/2009/09/08/4532496.aspx #xff08;书接上回#xff0c;继续#xff01;#xff09; 五、这个DSL框架有什么问题#xff1f; 有什么问题吗#xff1f;有一点#xff0c;并不严重。比如说#xff0c;我们在Env中声明了一些属性…http://blog.csdn.net/aimingoo/archive/2009/09/08/4532496.aspx 书接上回继续 五、这个DSL框架有什么问题 有什么问题吗有一点并不严重。比如说我们在Env中声明了一些属性和方法。对于Env这个对象Env { max: 100, min: -3, calc: function(adj) { … } } 我们要在calc()方法中访问max/min属性应该写成“this.max/this.min”这一则是不方便另外在用户的dsl代码中还不得不考虑“当前this是谁”的问题。这是问题之一。 第二个我们传入了一个evaluator(),相当于脚本执行器那么我们能不能在dsl()代码中也使用这个执行器呢也就是说我们的dsl不单是“domain-specific language”也可以是一个“domain-script language”的。 第三个问题我们是不是需要一个类似在JavaScript中的window对象的东西以便能引用到执行环境的全局。 这三个问题都应该是在DSL()层面解决的。简单说来第二、三个问题实质是在初始化环境environment使之具有某些在dsl代码中能访问到的性质。所以很容易处理function DSL(environment, evaluator, parser) { var dsl Scope(environment, Weave.call(evaluator, /^/, Block(parser, ‘body’)’/n/n’)); environment.system environment; environment[Block(evaluator, Name)] dsl; return Owner(environment, dsl); } 同理的用户可以在上面这里对environment加入更多性质这些都是可以在用户的dsl(…)中访问到的。以上面为例当用户传入的执行器evaluator是一个具名函数的时候则该函数名会成为dsl(…)环境中的可用的执行函数类似于exec, execScript或eval等)。例如function myeval() { … } dsl DSL(aEnv, myeval, aParser); dsl(function(){ myeval(…); }); 注意在dsl()访问到的myeval()方法其实不是用户原始的myeval()而是上述dsl变量的一个引用。这个从DSL()函数的实现中可以看到。 接下来就是上面三个问题中的第一个亦即是在calc()方法从必须使用this.max/this.min的问题。事实上这是因为声明calc方法的时候该函数位于Env变量所在的全局闭包里面。这样它就默认只能访问到全局的变量、标识符。所以解决这个问题的方法仍然和前面一样改变它的闭包位置——使用Scope()函数。如下function DSL(environment, evaluator, parser) { var dsl Scope(environment, Weave.call(evaluator, /^/, Block(parser, ‘body’)’/n/n’)); for (var n in environment) { if (environment[n] instanceof Function) environment[n] Scope(environment, environment[n]); } … } 现在有了一个新的、完善的DSL()。使用方法与前面是一致的。比如Env { max: 100, calc: function(adj) { return max adj }, //可以直接访问max了 show: function(msg) { alert(msg) } }; dsl DSL(Env, myeval, myparser); dsl(function() { show(calc(30)); //显示130 }); 最后留意一下当调用DSL()的时候我们标出了”Env”这个全局变量。注意的是我们直接使用了这个对象。那么它与使用Unique(Env)有什么不同呢答案是直接使用Env时在dsl(…)中的代码可以直接修改到Env中的成员而如果使用Unique(Env)则dsl(…)中的代码只会修改到Env的一个副本。这样一来我们就有机会为不同的dsl语言提供各各独立的环境了——这有点象沙箱。 六、变量泄漏 在JavaScript语言中有一个“根深蒂固”的问题就是“当在函数内访问一个不存在的变量时引擎会试图在全局变量环境中打找该变量”。这通常是很多很多烂系统的根源。对于我们上面的dsl语言来说系统其实只给出了五个标识符max/calc/show/system/myeval。其中的后面两个是DSL()函数在“语言引擎层面”提供的其它的则是Env环境变量提供的。“变量泄漏”带来的直接问题是对于上面的这个例子dsl(…)中除了能访问这五个标识符之外还能访问全局的window/String/Number/Math/RegExp/NaN等等预定义对象和属性。而这可能根本就不是我们的dsl语言需要的。 这怎么办呢 由于Unique()得到了Env环境对象的一个副本而且在dsl(…)中无法通过这个副本来修改原始的Env的成员也不能delete它。所以如果我们在Env的属性中加入这些“受保护的标识符”那么dsl(…)就只能访问到Env的这些属性而不会访问到全局里面的了。下面的代码简单地实现这一效果 Env { … }; protoected [window, setTimeout, setInterval, //window和Global的成员... Array, Object, Function, // 全局的对象构造器... null, undefined, //引擎定义的类似系统关键的... Env, tinyParser, dsl, myeval //用户代码环境中的... ]; protoected.forEach(function(item) { this[item] undefined}, Env); dsl DSL(Unique(Env), myeval, myparser); dsl(function() { show(Array); // 显示undefined Array ‘local defined’; show(Array); // 显示local defined }); 七、evaluator/parser是不是太简单了 当然。我们在evaluator, parser中基本什么也没有做当然是相当简单的。如果你要做一个完整的DSL那么你得花一些工夫来做语法解析并实现在语法树的基础上的代码执行、运行环境的维护等等。我QoBean的DSL()中主要是提供了一个运行你的代码的基础语言环境有点象是——嗯——沙箱。 当然除了沙箱的基本功能之外。DSL()通过environment来维护给用户代码的一组基本标识符或称为保留字并保证用户在不同的environment之间不会相互影响。 除了上述的基本描述之外我们最后再关注一下evaluator和parser的实现。对于下面的代码function myeval(source) { return eval(source); } function myparser(source){ source Block(source); } dsl(function() { show(minmax); show(calc(minmax)); }); 实际上的效果是dsl()将红色显示部分的函数作为一个一个参数source传入myparser()和myeval()。parser通过Block()取出这个函数代码的body部分然后交给myeval()中的eval()函数执行。也就是说我们在DSL()中调用Weave()的效果就是将myparser()和myeval()并在一起变成了function(source) { source Block(source); return eval(source); } 而dsl()最终执行的就是上面这个匿名函数。更进一步在environment上也会有一个名为’myeval’的方法指向这个匿名函数。 但是首先这里就有一个不小的问题’source’在这里也是一个标识符。在eval(…)中执行时代码是可以感知到这个标识符的——而对于dsl(…)中的用户代码source可能是另外需要的一个标识符所以这里我们要想办法屏蔽掉对这个变量名的依赖。这其实处理起来很简单function myeval(source) { return eval(arguments[0]); } function myparser(source){ arguments[0] Block(arguments[0]); } 你应该注意到我们用arguments[0]就可以简单地绕过一个入口参数名的使用了。这个很简单也很实用。 接下来我们总不能要求用户每次执行dsl(…)时都要传入一个函数吧我们最终声明的用户的DSL可能是相当怪异的、完全不符合JS的语法的根本就不能写到一个函数中去又该怎么办呢这个问题显然的——首先的——他该是parser的问题。因此我们也就简单地讲一下扩充myparser()的方法。比如说我们想实现下面的效果 当dsl(…)传入一个字符串时让myeval()直接执行该字符串当dsl(…)传入一个函数但函数体内是完整的整块注释时让myeval()执行这个注释块。例如如下的调用// 示例1 dsl(”/ apple.more-hi(form) % / tree.cleardo(function() .. ). / “); //示例2 dsl(function(){/* apple.more-hi(form) % tree.cleardo(function() .. ). */}); 现在我们需要进一步完善我们的myparser()提供一个基本的模式来支持这种设计。简单的方法如下function tinyParser(){ switch (typeof arguments[0]) { case ‘function’: arguments[0] Block(arguments[0]); arguments[0] arguments[0].replace(/^/s*///*([/d/D]*)/*///s*$/, ‘$1′); break; } /* 现在你需要 1、对字符串arguments[0]进行语法分析形成语法树或符号某种规则的代码块, 2、将结果传回arguments[0]。 */ } 当然由于代码的语法规则改变了所以myeval()的设计也应该发生相应的变化了。而这些就应该是DSL语言设计者的工作而不是QoBean在DSL()框架上要考虑的事情了。 八、终结DSL关键不在用什么语言实现而在于为什么Domain设计什么样的语言 我们用Javascript只写了不到了10行代码就实现了一个DSL()的通用框架但是我们却没有做出对任何一个真实的Domain有意义的DSL。对于Ruby、Python、Erlang还是Scala或者更原始的LISP或更新的F#这些基础语言对他们的选择更多的只是喜好或者出于某些局部的优异与方便的考虑与我们“设计一个DSL”是没有多大的关系的。一个DSL的设计在于对领域的、领域相关业务的分析与抽象。在这些分析、抽象的基础上进行语法设计、语义定义最终才表现为“怎样的一个语言”。当我们看到这个“表现”的时候整个DSL的设计都已经结束了——我们接下来只需要构建基本运行库runtime library以及其上的应用逻辑就好了。所以大多数看到某个DSL的人只是它的实现者和使用者而不是它的设计者。多数人只是埋头于使用或者激情于评说而忘了看看“一个具体DSL的背景”。 例如难道DOS批处理不是一个DSL吗10行的JavaScript难道不就是一个完整的DSL framework吗如果是那么我们还有必要讨论“什么是DSL”以及“怎样的DSL开发环境更好”的问题吗我们是不是看看“我们在什么Domain”以及“这个Domain如何描述、如何结构化和如何逻辑驱动之”这些问题是不是才是更关键的 上面两个示例中都有一个相同的dsl代码片断——这是一种假想的、完全不符合javascript的规范的新语言。示例1是通过一个字符串传给dsl()的示例2仍然是通过一个函数但函数体内是从/*..*/的一个注释块。 转载于:https://www.cnblogs.com/encounter/archive/2009/09/08/2188594.html
