[aosd-discuss] Fw: invasives aspects

[Awais Rashid]

Marc,

I do see your point about global reasoning. In a recent paper at MoDELS 2006
(A. Rashid and A. Moreira, "Domain Models are NOT Aspect Free", Proceedings
of MoDELS/UML, 2006, Springer, Lecture Notes in Computer Science, 4199, pp.
155-169.) Ana Moreira and I argued that AOSD is more than just about modular
reasoning. It is also about compositional reasoning (perhaps what you refer
to as global reasoning). The fact that you separate your crosscutting
concerns into aspects makes the dependencies and interactions amongst these
concerns more explicit and visible and hence helps you reason about the
composed behaviour of your system. This kind of compositional reasoning goes
hand-in-hand with any modular reasoning (whether for AOSD or not).
Component-based systems would require this too. You can reason about the
behaviour of a component (or aspect) in isolation but you also need to be
able to reason about what happens when it composes with other components (or
aspects). The history of Computing is full of disasters where the lack of
such compositional reasoning led to significant losses.

In a follow-up paper that is to appear at AOSD this year (R. Chitchyan, A.
Rashid, P. Rayson, and R. W. Waters, "Semantics-based Composition for
Aspect-Oriented Requirements Engineering", International Conference on
Aspect-Oriented Software Development (AOSD), 2007, ACM (Accepted to Appear))
we also show how semantics-based composition specifications help such
compositional reasoning in the context of aspect-oriented requirements
engineering. I will be happy to pass on a copy of that paper offline (after
the 20th) to you or anyone who may be interested.

As for Steiman's paper that you cite below, it uses obliviousness as a
fundamental property of AOP as a basis of this argument. There have been
plenty of discussions on this list arguing against that view over the years.
There is also work by Sullivan et al. and Aldrich that talks about explicit
interfaces between aspects and classes. The MoDELS 2006 paper that I mention
above goes into details about why obliviousness should not be considered
fundamental.

Awais.

> -----Original Message-----
> From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On Behalf
> Of Marc Eaddy
> Sent: 10 January 2007 01:06
> To: 'Gregor Kiczales'; 'Ashley at Metamaxim'
> Cc: 'AOSD discuss'; 'Alfred V. Aho'
> Subject: Re: [aosd-discuss] Fw: invasives aspects
> 
> 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=&CF
> ID
> =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
> 
> 
> 
> 
> _______________________________________________
> discuss mailing list    -    discuss at aosd.net
> 
> To unsubscribe and change options, go to:
> http://aosd.net/mailman/listinfo/discuss_aosd.net
> 
> Check out the AOSD.net Wiki: http://aosd.net/wiki