---------- Forwarded message ---------- Date: Sat, 16 Feb 2002 02:11:17 MET From: ECOOP 2002 - CyberChair To: lorenz@ccs.neu.edu Cc: boris@cs.lth.se, ecoop2002@borbala.com Subject: ECOOP 2002 Notification Dear David Lorenz, I am sorry to inform you that your paper, "Aspectual Collaborations for Collaboration-Oriented Concerns" has not been accepted for the ECOOP 2002 conference. We had a large number = of high quality submissions this year, and there were many good papers that we could not accept. The comments of the reviewers are included in this messag= e. Thank you for your interest in ECOOP 2002 and considering publishing a pape= r here. We hope to hear from you on future occasions. Yours Sincerely, Boris Magnusson ECOOP=B402 program chair *=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*= =3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D First reviewer's review: >>> Summary of the paper <<< The authors define a new way to do aspect-oriented programming over Java. One major contribution is the separation of the definition of an aspect with the attachment of this aspect to a host program. The system makes use of run-time meta-programming to give great flexibility to the aspects. Some checking can be done at aspect-compilation time but many checks while still happening before run-time must be deferred to aspect attachment time. The attachments are done by adding fields and methods and by intercepting calls to specific methods. The interception is done by replacing the callee with instrumenting code. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Comments <<< The system looks general and reasonably elegant. I have only two concerns that were not adequately (for me) addressed: @ unlike other AOP systems, more of the work (at least for attaching to methods) is done directly by a programmer using Java, rather than through special keywords (like "before" etc.) This gives a lot of generality, but does it not make it much more likely that the aspect will have bugs? @ A related concern: the use of thunks and return-value+exception objects enables generality (one can save up thunks and invoke them out of context etc) but there is also a run-time cost. A large system composed using AC would be slowed down markedly, wouldn't it ? minor points: Listing 1.5: I assume this sort of attachment causes an error if the names/signatures of the exported entities already exist in=20 the host program. page 8: sentence fragment "adviceSetGetAttribute in the interface." page 14: Listing 1.10: the keyword "reshared" seems misplaced when placed on an attached collaboration. It would seem cleaner to place it on the export statement in the attachment, as in: attach counter { HasAttribute +=3D Counter { export shared count; ... page 15: The "W.l.o.g." start of the paragraph is not a good=20 start. I stopped and thought "How can they ignore match?" It seems to presume the argument that comes later. A minor wording change would help here. page 18: item 2 should be capitalized "Depending ...." I ignored the appendix for the most part. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Points in favour or against <<< clearly written. Working (mostly) implementation. Seems an elegant solution. Hard to compare with related work. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D Second reviewer's review: >>> Summary of the paper <<< The paper proposes aspectual collaborations, a programming concept that encapsulates code crosscutting several classes. It discusses the structure of the concept using examples and its implementation. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Comments <<< This paper extends previous work of the authors on adaptive plug-and-play components. The proposal looks quite attractive, although some of the syntax and details of it probably still need some fine-tuning. I can see that the approach is more structural than AspectJ and that it has more felxibility than HaperJ. But the paper did nothing to convince me that the additional flexibility is worth the extra complexity. The proposal is quite complex, and it would be nice too see, what concrete benefits over HypeJ it provides. This motivation or evaluation section could be provided at the cost of the implementation sections (which is rather a quick and dirty prototype that just does its job, but does not appear to be anything durable). p. 2 You state that HypeJ has a flexibility problem, but there is no explanation or any example of what the "flexibility problem" is. p. 15 "w.l.o.g." - what is this? My dictionary does not say it. p. 16 What is "alpha converted"? =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Points in favour or against <<< +interesting and useful proposal -inadequate evaluation =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D Third reviewer's review: >>> Summary of the paper <<< The paper suggests a new language construct called "aspectual collaboration= s". The goal is to make aspects more reusable than e.g. in AspectJ, by supporti= ng that they can be applied to several different sets of classes. This is achi= eved by letting the aspects refer to the host methods and classes by means of fo= rmal names, rather than directly. A technique for matching names is used that al= lows an aspect to be applied to several matching configurations of names in the = host package. The paper presents the new language construct and its various details, and gives a couple of examples of its use. While I find the general goal of this paper interesting and a valid goal to pursue, I didn't find the examples particularly convincing. Also, I found t= he language construct rather inelegant with several ad hoc features. It is difficult to see how useful the suggested construct really is. There is a prototype implementation of the construct, but there does not yet seem to b= e any experience of practical use that can validate the approach. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Comments <<< I think you need to come up with more convincing examples before publishing this paper. I found the paper a bit difficult to read, in particular the introduction. = It is not until you get to the examples that things get clearer. You should explain the similarities/differences to AspectJ and Hyper/J in m= ore detail. Preferrably by commenting on your examples and explaining the drawb= acks of these other approaches for these examples. I had problems with appreciating the Get-Set example, because I can imagine many cases where only some of the fields should be provided with getters an= d setters, and not all. Your approach seems to provide notational shortcuts (through matching) only if you'd like the setters and getters for all field= s. I had problems with appreciating the "counter example" (funny name by the w= ay :-) for several reasons. First, it seems unnecessary and unclean to have to explicitly invoke the adviced methods. Why not provide a syntax which makes this unnecessary? You say that your system supports that the aspectual meth= od calls the method zero or many times, but you give no example of when this i= s useful. Second, why do you need to explicitly return the return-value, but = not provide the arguments? If the aspectual method should have so much influenc= e that it can call the method several times, should it not then also be able = to change the arguments of the call? Third, the use of "shared" and "static" d= oes not seem to make sense for your counting example. If I wanted to have a sha= red count for several variables, I'd probably not like to have it reset at any = call to a set-method. And why should I want to have ALL the variables shared. Wh= y not just two of the variables whereas a third would have its own counter? T= his all seems very ad hoc. I'd like to see brief examples of other uses of your idea. What about using them for applying design patterns for example? The idea of formal participa= nts classes seems perfect for that. The few examples you give on getters, sette= rs and counters do not seem worth this new complicated language construct.=20 =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Points in favour or against <<< + there is a prototype implementation + the main direction of work is important - the examples are not very convincing - the language construct seems complicated and not very elegant. I am not convinced that there is a sufficient increase in expressive power that justifies this complexity. - the work is immature (no actual experience from the construct is reported= ) - weak related work section. The advantages of the proposed approach compar= ed to earlier work are not clearly explained.=20 =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D Fourth reviewer's review: >>> Summary of the paper <<< The paper introduces the concept of aspectual collaborations (AC) as a nove= l software unit. The main idea of AC is to specify a collaboration with open roles, and then map this collaboration to the bas= e system (or another collaboration) by binding the expected roles. A main=20 advantage is that an AC defines a clear interface (both required and provid= ed) consisting of the expected features and of the externally accessible features of the AC. Hence an AC can hopefully be reused in many contexts satisfying the interface, and compiled separately. An AC may specify a pattern matching statement so that binding can be done=20 automatically. An AC can also define methods ("aspectual methods") which wi= ll intercept certain host method calls,=20 augmenting the latter with some aspectual functionality. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Comments <<< The introduced concept and its specification notation are rather rich; the problem is how to explain them in a conference paper. The current presentation allows the reader to understand the main id= ea on a general level, but it leaves many questions unanswered. This is of course a common problem, but I feel the pa= per could be made more digestible and=20 (even more) convincing. In particular, (i) There should be an abstract explanation of the main concepts, their relationships and the mechanisms in the beginning (before Sec 2). The syntax specification in Sec 1 is currently meaningless. (ii) The running example is nice for introducing the concepts, but it is difficult to really understand the examples with the current text. This may be partly because of the insufficient conceptual explanation. (iii) Implementation is important, but you cannot cover everything, so this paper could be more focussed on the concepts. You could shorten the implementation part and possibly refer to another pap= er for details. (iv) The examples are almost trivial which is good for explaining concepts = but not for motivating them. You should also give=20 a realistic (and perhaps even real) example of how your concept can be exploited for structuring a system, what could be an AC in a nontrivial case, how it would look like, and what are the expected benefits in that case. (v) Related work: you have presented your work in the AOP context, but anot= her context might be pattern formalization & specification: Patterns are collaborations with roles that = are bound to program elements. In fact, I could view an AC as a mixture of an aspect, a component, and a pattern. =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--= =3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D--=3D*=3D >>> Points in favour or against <<< In favour: - new ideas, or new combination of existing ones - existing implementation Against: - no experiences in practice - presentation could be better (see above)