关于闭包及变量回收问题

发表于

本文的诞生,源自近期打算做的一个关于javascript中的闭包的专题,由于需要解析闭包对垃圾回收的影响,特此针对不同的javascript引擎,做了相关的测试。 为了能从本文中得到需要的知识,看本文前,请明确自己知道闭包的概念,并对垃圾回收的常用算法有一定的了解。 问题的提出 假设有如下的代码: function outer() { var largeObject = LargeObject.fromSize('100MB'); return function() { console.log('inner'); }; } var inner = outer(

另类MVC模式 - 优势及实现

发表于

继续大逆不道系列…… 在上一篇中,提出了一个另类的MVC模型,与经典MVC模型有一些不同,那么自然需要描述这样的另类模型有什么优势,又能在怎么样的场景中使用。 逻辑划分 正如上一篇所说,这种模式下,最大的优势莫过于逻辑的清晰划分。在该模式的作用下,每一个Action都只要处理真正与自己有关的逻辑及数据,而不需要关心一些“通用”的内容,因为这些通用内容也成了独立的Action。 例如,继续引用上一篇中的页面设计,根据经典的MVC模式,我们不得不在一个Action中准备所有数据: public ActionResult ViewPost(int id) { ViewBag.

另类MVC模式 - 思考和雏形

发表于

这是一篇大逆不道的文章,其作用就是供大家娱乐以及批斗,因为此文所提及的思想,试图改变现有的著名模式MVC的结构,因此如果认为MVC优秀甚至完美的话,还请直接忽略此文,以免影响心情。 本文将提出一种类似MVC但又不完全是现有的经典MVC的模式,该模式仅基于HTTP的Web系统中对经典的MVC模式进行改造,其特点是将View前置,通过View的切分来切分逻辑,形成多次M-V-C交互,最终生成响应。 经典MVC模式 对于经典的MVC模式,虽然从表面上看完全是个“不需要解释”的问题,但是每个人的理解又不尽相同。在我的理解中,MVC模式可以用下面这张图来表达: 基于HTTP的Web系统里,在经典的MVC模式中,一个请求的处理过程大致分为: Controller处理原始请求,根据请求的数据与系统的配置,

不完美沙箱 - 变量定义及查找

发表于

时隔N久,继续生产,年底实在忙…… 在上一篇发表之后,有网友指出这个沙箱过于复杂,事实上一些更简单的代码也能完成同样的效果,例如: var proxy = { document: new DocumentProxy() }; function(window) { // 开发者提交的代码 }.call(proxy, proxy); 通过call和函数参数来劫持this及window这两个指向全局对象的变量,以达到屏蔽全局对象的目的。 但是这个方式虽然简单易懂,却有一个非常重要的环节无法照顾到,即全局环境下LexicalEnvironment和VariableEnvironment和ThisBinding均是全局对象,这一特性意味着在全局环境下执行的代码将同时满足以下4个条件: 通过var x

不完美沙箱 - 模拟全局对象

发表于

上一章中,经过对标准的查询、翻阅、解析,终于在绕了一个大圈之后,明白了全局对象的特征,并明确了模拟一个全局对象需要的内容,还为此编写了简单的测试用例。本文将从第1个测试用例着手,放眼与全局作用域的VariableEnvironment、ThisBinding以及window别名这三者的一致性,来推导出一个沙箱的原型。 所谓纰漏 在开始这一章以前,首先不得在这里道个歉,原因很简单,我对标准进行了误读,且在没有测试的情况下就开始了这一系列的博客。事实上,以我的思路,是无法制作出一个理想中的沙箱的,虽然可以控制住第三方代码的作用区域,但是无法做到完全的透明,其主要问题出在这里: var x