javascript程序的動(dòng)態(tài)行為分析外文翻譯-其他專(zhuān)業(yè)(編輯修改稿)
2025-02-24 06:29 本頁(yè)面
【文章內(nèi)容簡(jiǎn)介】 language” of the Inter and is targeted by code generators from the likes of Java and Scheme. In response to this success, JavaScript has started to garner academic attention and respect. Researchers have focused on three main problems: security, correctness and performance. Security is arguably JavaScript’s most pressing problem: a number of attacks have been discovered that exploit the language’s dynamism (mostly the ability to access and modify shared objects and to inject code via eval). Researchers have proposed approaches that marry static analysis and runtime monitoring to prevent a subset of known attacks. Another strand of research has tried to investigate how to provide better tools for developers for catching errors early. Being a weakly typed language with no type declarations and only runtime checking of calls and field accesses, it is natural to try to provide a static type system for JavaScript. Finally, after many years of neglect, modern implementations of JavaScript have started to appear which use state of the art justintime pilation techniques. 2. Motivation and Related Work The original impetus for our interest in JavaScript was to assess the feasibility of a static type system able to successfully and meaningfully type check existing JavaScript programs. Other dynamic languages such as Scheme have had recent success introducing gradual typing systems, but they have stopped short of type checking objectoriented extensions (implemented by macros in Scheme). For JavaScript, Anderson et al. proposed a type system with definite and potential types, while Heidegger and Thiemann following up on some of their earlier workpropose recency types in, and Furr et al. proposed a related system for DRuby. While all of these type systems acknowledge some minor simplifications to the target language, they rely on fairly similar assumptions. For instance, Thiemann writes: “Usually, no further properties are defined after the initialization and the type of the properties rarely 中原工學(xué)院信息商務(wù)學(xué)院畢業(yè)設(shè)計(jì)（論文）譯文專(zhuān)用紙 第 9頁(yè) changes.” Common Assumptions about the dynamic behavior of proceed to enumerate the explicit and implicit assumptions that are monly found in the literature and in implementations. 1. The prototype hierarchy is invariant. The assumption that the prototype hierarchy does not change after an object is created is so central to the type system work that chose to not even model prototypes. Research on static analysis typically does not mention prototype updates. Yet, any modification to the prototype hierarchy can potentially impact the control flow graph of the application just as well as the types of affected objects. 2. Properties are added at object initialization. Folklore holds that there is something akin to an “initialization phase” in dynamic languages where most of the dynamic activity occurs and after which the application is mostly static. For JavaScript this is embodied by the assumption that most changes to the fields and methods of objects occur at initialization, and thus that it is reasonable to assign an almost plete type to objects at creation, leaving a small number of properties as potential. 3. Properties are rarely deleted. Removal ofmethods or fields is difficult to cmodate in a type system as it permits nonmonotonic evolution of types that breaks subtyping guarantees usually enforced in mode
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號(hào)-1