[aosd-discuss] Fw: invasives aspects

[Marc Eaddy]

Dear Gregor,
 
	I respectfully disagree with some of your arguments.  Let us
consider only AspectJ-like (pointcut/advice) AOP languages.  Even if they
enable modular reasoning for the aspects themselves, they prevent modular
reasoning for the rest of the program.  These languages allow the control
flow of a program to be arbitrarily changed and private fields and methods
to be accessed.  With some strategically placed 'around' advice, I can
change a sorting program into a web server.  Without global reasoning, it
would be impossible to predict the behavior of the program.  Even your
"display updating" aspect requires global reasoning if other aspects apply
to it.

	As pointed out in [1] and by others in this discussion, strictly
speaking, polymorphism prevents modular reasoning.  These "lapses" in
modular reasoning are considered acceptable because, in contrast to advice,
polymophism is limited (only calls to virtual methods), restricted (only
overridable methods), not oblivious (only these call sites), and intuitive
(e.g., some kind of shape will draw itself when I call Shape.draw()).
Modularity, evolvability, reusability, and modular reasoning would improve
considerably if AOP languages were similarly restricted.

Kind regards,

	Marc Eaddy
	PhD Student
	Columbia University
	http://www.columbia.edu/~me133

[1] Friedrich Steimann, "The Paradoxical Success of Aspect-Oriented
Programming," OOPSLA '06 
http://portal.acm.org/ft_gateway.cfm?id=1167514&type=pdf&coll=GUIDE&dl=&CFID
=15151515&CFTOKEN=6184618
  
________________________________

	From: Gregor Kiczales [mailto:gregor at cs.ubc.ca] 
	Sent: Tuesday, January 09, 2007 1:15 PM
	To: Ashley at Metamaxim
	Cc: AOSD discuss
	Subject: Re: [aosd-discuss] Fw: invasives aspects
	
	


	On 1/9/07, Ashley at Metamaxim <ashley.mcneile at metamaxim.com> wrote:
	

				 
		> The various arguments that AOP does not support modular
reasoning invariably rest on the notion that we ought to be 
		> able to do modular reasoning without even simple machine
support -- to be able to print code out and reason about it 
		> effectively from the printouts. Since no practicing
developer tries to reason about code today without tool support, even 
		> for OO programming, it seems an unrealistic constraint to
place on AOP.
		 
				The paper I cited does not suggest that
reasoning must/should be possible without tool support. I can see that using
a tool might make reasoning easier, but it is difficult to imagine that it
can affect whether reasoning is theoretically possible.


	I believe that it does actually.  Consider:
	
	
	obliviousness threatens conventional modularity 
	principles and undermines a programmer's ability to reason
	locally about the behavior of their code.
	...
	to understand
	the semantics of code in an aspect-oriented language such as
AspectJ,
	programmers will have to examine all external aspects that 
	might modify local data structures or control flow.
	

	The idea that you have to manually examine all aspects that might
affect the behavior at a join point comes directly from the idea of not
being able to use tool support to do it. The theme underlying this is that
OO, by comparison, is amenable to modular reasoning because you can follow
an explicit chain of named reference links (calls, instantiations etc.) to
see what is happening. But, if you allow even very simple AOP tool support,
then you recover the exact same sense of being able to follow explicit
references to code that might run at the join point. 
	
	

				> IMHO all of these arguments against
'invasive' advice miss the key point: without AOP modularity constructs,
true 
		> crosscutting concerns cannot be reasoned about in a
modular way. With AOP constructs they can.
		 
				I did not understand this comment. Can you
elucidate, please?



	In the paper that Mira and I wrote (AOP and Modular Reasoning) we
show that the canonical display updating concern, implemented without AOP,
requires whole program searching in order to reason about it. By contrast,
AOP supports modular reasoning for display updating, as long as you allow
simple tool support. This part of the paper -- the demonstration of the
failure of non-AOP to be able to support modular reasoning in some cases, is
I believe critical. Unfortunately it seems we weren't clear  about that. 
	
	P.S. Note that the central technical contribution of the Harmless
Advice paper is not at question. Its great stuff in  terms of reasoning
about the interaction between crosscutting concerns at a join point. 
	


		Rgds
		Ashley