http://www.cs.washington.edu/homes/djg/papers/oopsla2010jsaspects.pdf

Reading Group Flow

• Peng: 1st Present overview of paper
• James: 2nd Open discussion to participants

Background (what you can expect from what we know)

• Peng: more expertise in AspectJ than James
• James: more towards Javascript and Javascript-extensions

James's Review

Motivation

• Current meta-programming syntax of writing Firefox extensions for Javascript requires wrapping and monkey-patching, both of which can be improved by using an AOP approach.

Contributions

• Dynamic-weaving (details in section 4.1)
• Weaving into function closures
• Dynamic disablement

Areas of Potential Improvement

• Evaluation of Performance: The paper did not provide any absolute performance measurement in response times (ms.) Author used his own Javascript compiler to compare the performance of monkey-patching (not-AOP) and his proposed AOP syntax. Paper would be more effective if it provides some concrete comparisons of how the performance of paper’s JIT compiler would compare to existing Javascript engines such as Firefox’s Rhino and Chrome’s V8.

• C# Implementation hinders practicality: The initial goal of the paper is to provide an easier syntax to develop Firefox extensions. However, because the paper’s JIT complier is implemented in C#, so far there’s still not a functioning web-browser that supports the Aspect-oriented development of the original Firefox extensions.

• Statement_containing(): Syntax is not much more graceful than pure monkey-patching. Good thing the author’s AOP supports containing the environment for function-closures.

• Not supporting event-dispatch: Control flow in Javascript is hugely event-driven. So far JIT compiler still does not support event-displatch (section 4.3.5)

Discussion

• Section 4.3.3 Why: Each base pointcut pi must be the same type of poincut – all callee, all field, or all sstatement_containing(). Is it practical?

• Implementing a debugger: Based on the way the paper implemented dynamic-weaving of closures in run-time, how easy/difficult do you think it would be to implement a console-based debugger like the one offered by Safari/Chrome?

• Do you think the authors did a good-enough job in enabling AOP in Javascript, compared to related work. Should they do more (e.g. offer more in their AOP-JS solution so it gets closer to AspectJ), or less (current features are more than enough)?

Belief

• Good attempt to pioneer and apply an aspect-oriented approach for meta-programming and writing extensions for Javascript applications. Liked the structure and flow of paper in which it used specific examples to showcase the need for AOP.

• Would appreciate the paper more if details in evaluation and performance are better thought out.

• Look forward to seeing IE to support Firefox extensions, whether developed with or without AOP-Javascript.

-- Main.tklo - 30 Nov 2010

Peng's Review

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.

Questions

1. 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.