Course Assignments
Aop
Discussion questions
- Discussion questions
- Session 2 (Mon 10 Sep)
- Session 3 (Thu 13 Sep)
- Session 4 (Mon 17 Sep)
- Session 5 (Thu 20 Sep)
- Session 6 (Mon 24 Sep)
- Session 7 (Mon 1 Oct)
- Session 8 (Thu 4 Oct)
- Session 9 (Mon 8 Oct)
- Session 10 (Thu 11 Oct)
- Session 11 (Mon 15 Oct)
- Session 12 (Thu 18 Oct)
- Session 13 (Mon 22 Oct)
- Session 14 (Thu 25 Oct)
- Session 15 (Mon 29 Oct)
- Session 16 (Thu 1 Nov)
Session 2 (Mon 10 Sep)
Mark: Information questions: - Are there any example of aspects applied to functional programming languages? - Have other people done any large experimental studies? - Are there other, non-aspects, solutions to the problem sketched in the paper? Discussion questions: - As said in the paper, aspects take over most of the optimalisation work, normally done by the compiler. In what sense is this a good thing? Is it not extremely hard to write aspects by hand and also, don't you need a lot of them to make it efficient in larger, more complex, systems? - The paper talks about functionality which cross-cuts the basic system functionality. They say aspects help you capture these requirements in actual code. Do you think aspects capture all the cross-cutting functionality? Robin: I see someone posted a question about optimising earlier today. To be honest, I had similiar questions about it after reading the paper: - Is AOP really a new programming paradigm or is it just another optimisation technique based on existing languages (the paper talks mostly about optimisations anyway)? - How does it resolve the complexity of existing languages? It seems that adding code seperation between an aspect and a compenet will increase the overall complexity of the system. And really a genereal question about the relation of the components and aspects to the weaver. I understood that the aspects are some sort of rules which control the overall output of the weaver. So I assumed aspects are somewhat the rule base by which the weaver will work. The weaver will have to work with components and aspects to generate the output itself. Correct me if I'm wrong though. So, my question is: How do aspects control the weaver? I think I understood the main idea but I think the paper says little about the actual details of the aspect language. It's really a grey area at this moment. Christiaan: - At the top of page 221 they say that the current state of AOP is analogous to that of OOP 20 years ago. I hardly ever hear anything about AOP nowadays and since this paper was written about 10 years ago, does that mean that the development of AOP is just going slow or that it's just not as revolutionary and great as they hoped it to be? - It might be me, but the "tangled" code at the top of page 224 seems to be easier to understand than the aspect code on page 229. So my question is: could you explain the code on page 229? And also, does this really make it easier to program? - In the table on page 227 they give a couple of examples but they fail to explain for a lot of them why exactly they are aspects (or why other things aren't). Is there a better way to define when something in a program can be seen as an aspect? - Figure 2 on page 230 shows 3 steps for a program from source to a C program. Now if you compile that C program that adds another step. What happens when the end result crashes? Will it be traceable at all what part of the original code caused the error? I.E. is it possible at all to do decent debugging? - At the bottom of page 230 they mention that their weaver is not a "smart" compiler and that the programmer has to do everything himself. In the footnote they say that's not so bad, but could it be done better? Would it be possible to make such a "smart" compiler? And would that be useful or would that actually completely contradict the whole point of AOP? - On page 235 they mention a 'join point representation', but it's not really clear to me what that would be. Could you shed some more light on this? Peter: What kind of 'join points' are possible? Is it limited to matching on (nested) functions calls? Or is it also be possible to hook into things like an assignment? Or when an object is passed around? On Sun, Sep 09, 2007 at 02:07:12AM +0200, Christiaan Hees wrote: - Figure 2 on page 230 shows 3 steps for a program from source to a C program. Now if you compile that C program that adds another step. What happens when the end result crashes? Will it be traceable at all what part of the original code caused the error? I.E. is it possible at all to do decent debugging? related to this: what if the programmer isn't satisfied with the result of its aspect programs, of example the end program is still using to much memory. Would there be any way to find out which aspect program needs to be improved, or where another one might be needed? (Or conclude that this is as good as it gets...) At the bottom of page 228 they show that the program is slightly adapted to make the use of aspects possible (/easier). Does the programmer need to know the kind of aspect programs that are going to be applied before starting to code? Martijn: How does one recognize a problem can be easily solved using AOP? Or, how does one recognize whether an existing solution can be simplified using AOP?Session 3 (Thu 13 Sep)
Peter: Is it possible for an aspect to extend another aspect (maybe that would be another way of doing the MoveTracking and Mobile examples?). Or would that just come down to re-using the pointcut's ? AspectJ and IDE integration: are there tools that allow for easy integration, like some tool that tells given some pointcut where it will be will crosscut the program (/source code) ? Or should every IDE extension implement this logic itself? Robin: - At chapter 3.3 in the paper, they state that upon arrival at a join point, all advice in the system is examined to se whether any apply at the join point. It collects all advices and try to match those with the current evaluated method/function. Can this have some sort of influence on the system performance (especially on more advice given ;-)? As follow up question: - At chapter 4 they say that the AspectJ language uses a compiler. At chapter 3.3 they talk about runtime (if I'm correct though). What's the implementation? Is it both a compiler and runtime library or just the compiler? Alesya: 1. The paper and tutorials on AspectJ say that the three types of advice that are available - before, after and around - allow applying advice to methods. But what if I want to insert a logging statement somewhere in the middle in the method code? Or when I do debugging and I want to see the intermediate results, I would have a log.debug statement inside a method. Is it possible to somehow accomplish that with AspectJ? I could think of writing a pointcut for every logging (debugging) statement that's in the middle of the method. But I was wondering if there is another way of doing this? 2. Another question that I have is about precedence. Imagine defining before, after and around advices for the same pointcut, I wonder what the execution order of the advices will be? Will the order be before, around and then after or the other way around? Martijn: Can you please discuss the primitive pointcut cflow in detail? I am particularly interested in the semantics of the composition of those pointcuts: cflow(P) && cflow(Q) and cflow(P && Q). This is explained briefly in the Programming Guide, but I find it very difficult to understand. Perhaps you can give a clear, concrete example? Also, what is the difference between cflow and cflowbelow, and cflow and within? Is within just a more specific version of cflow? Christiaan: When you have something like: receptions(void FigureElement.incrXY(int, int)) and the example from fig. 1. in the 2001-ecoop paper... If you call Line.incrXY(int,int) it will match... but what if that method forwards the call to Point.incrXY(int,int)? Will it match again? And if so, is there a way to prevent this bubbling up effect? Or don't you need this in practice anyway? But at the top of page 17 they seem to say that you can do that with cflow, but it's still a bit unclear. Is this indeed the way to do it?Session 4 (Mon 17 Sep)
Mark:- How is the tool support for using aspect-oriented implementations of design patterns?
- The papers both discuss the implementation of design patterns using aspect-oriented implementations. Especially the HK paper describes there general aspect solution using a special protocol aspect. I was wondering whether there are more of these "aspect patterns".
- The papers concentrate on the implementation advantages of aspect-oriented and object-oriented implementations of the design pattern. However, it is still a lot of work to go through all the code to understand the program. UML makes our life easier by giving us a picture of the system. Of course, this is all in favour of object-oriented programs where an UML entity more or less equals an object in the system. What are the plans for aspect-oriented models in this sense? Are there plans for the UML standard to support aspects?
- Both papers agree on some design patterns that aspect-oriented implementations improve the modularity. So it seems like if this is the case, then we can only gain by using the aspect-oriented approach. Or are there also disadvantages by using aspects in design patterns?
- In The Java Programming language (3rd edition) they state that multiple inheritance complicated the design and use of class hierarchies (and so they ditched it). However, AspectJ provides a way to attach interfaces and implementations to existing classes. Will this AspectJ-feature make the designs of your AoP programs more complicated?
- In the first paper, on page 167, they state that they can generalize pattern code. I'm not following that actually. How is this possible?
- In the second paper they have an example with an UML diagram shown. Is there a standard UML extension (UML2.0 is extendible; a great example of this is Realtime-UML) for AoP?
import junit.framework.Assert;
import org.junit.Test;
public class Universe implements Singleton {
@Test
public void test() {
Assert.assertTrue(new Universe() == new Universe());
}
}
It is every programmer's intuition that this test should fail, yet it
succeeds. Can you write a different generic implementation of the
Singleton pattern that does not abuse constructor calls like this?
When you have your different implementation: do you really need AOP for
this, or would the standard Java language suffice?
Session 5 (Thu 20 Sep)
Alesya: 1. In the Advice Weaving paper on page 27 they show a woven code fragment for the before advice. Could you please explain why do they create temporary variables to operate the before advice (although maybe for the after advice that would be sufficient). Seems like they create redundant variables. 2. How is it determined that the optimization of replacing thisJoinPoint with thisJoinPointStaticPart can be made? 3. In the paper about semantic-based weaving, they say that it is a powerful mechanism. Maybe you could give the examples when semantic-based weaving might be beneficial. Robin: The following questions are related to the performance of the AspectJ weaver, as stated in chapter 6 of the "Advice Weaving in AspectJ" paper: - In Chapter 6 the authors state that the final approach to improving performance is to support incremental recompilation. Is this issua already resolved in newer version of AspectJ and how does it affect performance? - As a more global question: the paper describes some performance issues for an AspectJ version prior to 1.1. The current version is 1.5.3. What are the performance improvements of the newer versions in comparison to the older versions? To be honest with you: I tried reading the second paper and it took me a long time to finish it. I thought the paper was quite difficult (for me) to read. I think I don't understand it at this moment. So for I've only come up with one question: - The introduction talks about using Aspect Oriented Programming at design time or at the requirements analyses instead at implementation time itself. The paper then talks about several algorithms to make this possible. Is it already used in the real world? Or is it still onlye theory? Mark: In the paper "An Overview of AspectJ", session 2, page 17, section 4.1 "compilation of advice bodies". They say, that an 'around' advice is compiled into multiple methods. Could you explain to me why, since I do not understand the way they explain it and the other paper doesn't specifically mention it. In the second paper, they start by saying that semantic-based weaving is "far more appealing and powerful mechanism". Could you point out some of the advantages and disadvantages of this? Also, is it useful to be able to do semantic-weaving? Later on they are rewriting HMSC to other HMSC, because of breaking some infinite cycles (I think). Could you shed some more light on this specific part? What are they trying to accomplish? How do they try to do this? An why is this valid, since it seems to me like they are changing the flow (see figure 11). The whole second paper is pretty theoretically, but they actually say they are still implementing this in a framework called UMLAUT. So, could you show a more concrete example of this weaving? What would I have to type into this framework to get something, for example. Peter: In the paper 'Advice Weaving in AspectJ', section 7, show that there's quite a difference in performance depending on how you write the aspect. Are there easy ways (besides benchmarking) for a programmer to find out if his aspected can be improved. I was also wondering if they have made (some of) the optimisations mentioned in the paper, like more/beter fastmatch or the 'basic engineering' for reducing the overheads. Christiaan: In the Hilsdale paper on page 33 at the top left they mention that some tests were found to fail. Do you have any idea why they failed? It seems to me like an important issue when you add a simple logging Aspect that some bechmarks actually fail, but they don't seem to mention it anywhere else. Could it be that the aspects changed the code in a destructive way? i.e. are there situations where it's not trivial to add logging with aspects?Session 6 (Mon 24 Sep)
Mark: - Why won't they simplify the language to make it easier to parse? Would that result in a loss of expresiveness? Or is it actually possible to change the syntax in such a way that it is easier to parse, while maintaining it's strength? - Could you tell something more about SDF? Are there applications which use SDF? What are the advantages and disadvantages of SDF, in general? Maybe you can also give a small sketch on how SDF is implemented. Christiaan: On page 213 at the bottom right they say that the Pattern Parser is handwritten which is a bad thing. Is there a good reason to do this part by hand? Would it be possible to also use a parser generator here? Some sort of subparser? Or would that be a waste since you can't reuse the (although perhaps incorrect) tokens anymore? Is the aproach of the abc parser inherently better than the one used for ajc? Is there such a thing as Parser Aspects? They talk about Mixins, but can't you consider them also as some sort of Aspects? On page 221 at the bottom right: "AspectJ imports the grammar mixin JavaMix four times, once for every context." This sounds to me like the JavaMix could be an aspect of those contexts (crosscutting them). On page 224 on the bottom right they mention: "the cost of scannerless parsing is linear in the length of the input, although with an important constant factor." I can't see the constant factor in the graphs. They all seem to originate from 0,0. If there was a constant factor wouldn't they originate from 0,50 or something like that? Alesya: I can imagine that lexical analysis of AspectJ is supposed to be difficult as there are several different languages that have to be parsed: regular Java code, aspect and pointcut definitions. The paper says that the lexer is stateful which means it recognises different tokens in different contexts. I was wondering if the actions taken by the lexer when encountering one of the keywords are customisable. Martijn: - SDF is a parser generator. For which language(s) does it generate parsers? - Is it possible to mix normal code with SDF grammars, like it is with other parser generators such as JavaCC or ANTLR? - Can you please give a small example that shows the power of mixins (section 5.4), and their difference from normal imports? Peter: The abc compiler is intended for easy extending, but ajc is the official compiler. Seeing the difference in the way both compilers work, are there any extensions that have been developed on abc been ported to ajc?Session 7 (Mon 1 Oct)
Mark: - Are there other approaches to using aspects at design level? How do they work? - Is this Theme-approach commonly used in practice? Martijn: Can you explain figure 5 to us tomorrow, please? And can you tell us what the consequences of the determination of the crosscutting themes are? How do they affect the implementation of the system? For example, if the system is implemented in AspectJ, does every Theme aspect correspond to an AspectJ aspect? Robin: Are there any tools that can be used for this approach? Alesya: 1. From the diagrams in the paper it seems that Theme/UML makes use of both class diagram notation and also sequence diagram notation. I wonder what additional information does those diagrams have to capture that allows to depict how cross-cutting concerns relate to each other? 2. Discussion question: There may be situations when requirements frequently change in the software development process. Do you think that decomposing requirements into aspects helps dealing with any changes when requirements evolve? Christiaan: They talk about lexical analysis being done by Theme/Doc a couple of times, but isn't that terribly inaccurate and error prone? They actually mention in 4.1 that they had problems with synonyms and I imagine there will be other problems like that. So wouldn't it be easier to model it by hand instead of letting a tool try to guess it and then fix the mistakes of the tool?Session 8 (Thu 4 Oct)
Martijn: In section 2.1, they write: "Note that the scope of the advice does not include access to any of the fields of the Iterator object" Is their analysis of only locally used objects always correct? Or are there ways to "fool" their analysis? With what effects? Robin: 3.2 Pointer Analysis:- The pape talks about an existing interprocedural, flow sensitive, context-sensitive, bottum-up combined pointer and escape analysis. Besides the very long sentence (
) I never heard of such thing. Could you explain it a bit? Or talk about it a bit? What is it? How does it work?
- The paper talks a bit about Report Generation. They tried to explain with an example earlier in the paper, but how do you interpret/read these reports? It seemed a bit vague for me.
- They talk about a report generator they wrote. Where can you find it and how does it work? Can you show an example of the working (a website would also qualify ?