Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
http://www.cs.washington.edu/homes/djg/papers/oopsla2010jsaspects.pdf![]() James's Review | ||||||||
Line: 37 to 37 | ||||||||
-- Main.tklo - 30 Nov 2010
Peng's Review | ||||||||
Added: | ||||||||
> > | This paper deals with a problem of JS programming: the JS code running for a Web page is from different sources (userscript, third-party JS libraries, Ads on the site and browser extensions), and all the JS code is “mashuped” in a client’s browser. A worse situation is that some JS might even change the behaviour of other JS code.
Currently, there are two “solutions” for this “JS-mashup” problem: wrapping and monkey patching. However, those techniques are not only error-prone, but cannot completely solve the JS modification problem. They all have some limitations. The wrapping technique can only add code before and after the target function, and it cannot modify the internal control flow of the function (the middle of the function). The monkey patching technique can easily lose the closure environment since this technique uses “toString()” to output only the textual representation but not the environment of the closure, which makes the monkey patching approach often fails silently, and makes the errors hard to debug. In this case, both of the existing techniques do not totally solve the JS-mashup problem.
In this paper, the authors proposed an aspect oriented approach for JS. Instead of providing a better modularizing code by separating cross-cutting concerns like AOP, this paper provides a concise and accurate way for the JS code modification problem. Basically, this paper borrowed many ideas and techniques from the AOP domain, for example, dynamic weaving, weaving order, cflow… Their approach does not provide a big contribution for the aspect community. However, their paper does provide a complete solution for a common JS programming problem and they also provide a formal language expression for this. Three key features which have been provided by their project are: dynamic weaving; weaving should apply to closures rather than variables; disable or re-enable advice dynamically.
Questions1. The authors mentioned that some JS code modifications cannot be solved through wrapping or monkey patching techniques. However, their evaluation for 20 Firefox extensions did not show how many percentage of the JS code modification falls into that situation. 2. How does their stack filter compare to AOP’s cflow? 3. There are many interesting performance evaluations from the AOP community. Can the authors apply those evaluations to this aspect enabled JS compiler? Currently, their performance evaluation is not that interesting. | |||||||