[aosd-discuss] invasives aspects --> answer to Mira

[Marc Eaddy]

Hi Mira,

	Thank you for your thoughtful response.  I've responded to your
comments below...

Warm regards,

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

> -----Original Message-----
> From: Mira Mezini [mailto:mezini at informatik.tu-darmstadt.de]
> Sent: Wednesday, January 10, 2007 9:43 AM
> To: discuss at aosd.net
> Cc: mezini at informatik.tu-darmstadt.de
> Subject: Re: [aosd-discuss] invasives aspects --> answer to Marc
>
> ...
>
> > Marc Eaddy writes:
> >
> > 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.
> 
> Let me rephrase your last sentence first... Personally, I can't make
> much
> sense of the phrase "languages allow the control flow of a program to
> change..."
> 

Sorry for my poor wording.  What I meant was that advice can alter the
control flow of a program arbitrarily.  For example, an advice can override
the control flow of a base method in the same way that a subclass can.  The
difference is that AOP provides many more ways to override control flow than
subclassing, and the unrestricted use of this power hinders the ability to
reason about a module in isolation.

> ...
>
> The rationale for doing so is to enable programmers to express
> EXPLICITLY
> sophisticated interactions between crosscutting concerns. So, an AO
> programmer that has to model the interaction between two concerns whose
> control and data flow crosscut in non-obvious ways uses AO features as
> the
> ones that you describe above. Now, I ask you to consider expressing the
> same
> interaction without AOP.
>

Agreed.  Aspects allow the interactions of crosscutting concerns with other
concerns to be expressed more explicitly.  However, global reasoning is
still required because aspects can advise other aspects.

>
> Will be able to express the interaction in a
> more
> abstract way? I mean, will you be able to better abstract over
> irrelevant
> implementation details in expressing the interaction?
> 
> The ICSE paper by Gregor and myself [1] answers these questions with
> NO.
> This is to say that the fine-grained interaction between the concerns
> under
> consideration will have to be expressed in the non-AOP version, as
> well. It
> is inherent to the existence of the crosscutting concerns that the
> programmer wants to express. Compared to the AO version, the
> interaction in
> the non-AO version will be expressed implicitly and in a less (or
> equal)
> abstract way. It will be expressed by means of local variables used as
> flags
> for keeping track of relevant control flows, by means of scattered
> method
> calls following immediately after access to private fields or private
> method
> calls, etc.
> 

Localizing crosscutting concerns and making their interactions more explicit
come at the cost of requiring global reasoning and compromising information
hiding.

>
> This is one of the main points that the ICSE paper
> makes:
> In the presence of crosscutting concerns NON AOP DOES NOT SUPPORT
> MODULAR
> REASONING.
> 

Modular reasoning means I can understand EXACTLY how a module behaves by
looking at its source code and the code of the modules it explicitly
references (barring polymorphic functions).  Your ICSE paper adds the
requirement that I also have to look at the aspects that reference the
module.  While the paper calls this modular reasoning, this prevents modular
reasoning in the sense I've described.

My feeling is that you want modular reasoning to mean the ability to
understand how a CROSSCUTTING CONCERN (not a module) behaves and interacts
with the base program.  I would use a different term, e.g,. "compositional
reasoning" as Rashid suggested, rather than redefining an existing term.

>
> Another point that the paper makes is that by making the interaction
> explicit and by providing some means of quantification over control and
> data
> flow (which may be used to express the interaction more abstractly) AOP
> better supports modular reasoning.
>

I agree that AOP makes it easier to understand the behavior and interaction
of crosscutting concerns.  Although since aspects apply to other aspects,
global reasoning is still required.

>
> This said, more powerful means of referencing are needed to express the
> interaction more abstractly and to also help with modular reasoning (I
> strongly recommend also reading [2] and [3]).
>

I agree these approaches are a step in the right direction.  The Display
example written in Alpha preserves modular reasoning in the sense I've
described.  However, I'm purposely restricting the discussion to
AspectJ-like (pointcut-advice) languages to make a point.

> 
> > Marc Eaddy writes:
> >
> > 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.
> 
> Well, it is always possible to shoot yourself if you want to do so.
> In a non-AO language I can use a lot of local and global variables
> passed
> around from remote places to simulate the effect of an around advice
> (at the
> end all languages we are talking about are Turing complete). So, what's
> the
> point?
> 

The point is that it is easier to shoot yourself in the foot with AspectJ,
since AspectJ disregards Java's linguistic mechanisms for information
hiding.  So even if I follow all the accepted software practices for
creating good modules, such as making fields and method private, declaring
methods as final, and providing a minimal and complete module interface,
it's still possible for an AspectJ programmer to circumvent this by creating
dependencies on private implementation details.  I can no longer assume that
normally safe implementation changes will not break clients.

> 
> AO languages
> do provide linguistic means to explicitly restrict the scope of the
> effect
> of the aspect as well as what the aspect is allowed and not allowed. I
> can
> use pointcut-advice of AO languages (i.e., quantification mechanisms)
> to
> control the scope of the aspects.
> 

Your saying the aspect defines its scope, not the base module.  However,
this prevents modular reasoning for the base module since you still need to
know what aspects apply to it (global reasoning again).

> 
> I can also define dynamic scopes, as it is possible with the deploy
> construct of Caesarj-like languages [5].
>

This is a great way to promote more disciplined use of aspects, but my
modular reasoning arguments still apply.  If an aspect can still modify the
control flow (barring polymorphic functions) of the Point module and access
private implementation details, I can't reason about the module using
modular reasoning.

> 
> To recap: AO languages provide linguistic means to enable programmers
> to
> express restrictions when needed.

As I mentioned above, while these AO languages allow the aspect developer to
express restrictions, they do not allow the module developer to.  Thus, the
module developer cannot reason about the behavior of their module without
knowledge of all the aspects that may apply to it.

> What you require instead is to
> restrict
> the linguistic means.
>

Restriction mechanisms and information hiding exist for the purpose of
helping programmers write more modular software.  AspectJ ignores these
restrictions.

The tradeoff between modular reasoning and modularizing crosscutting
concerns should be justifiable, in the same way that the tradeoff associated
with using polymorphism is justifiable.  AspectJ's ability to *localize*
crosscutting concerns does not offset the overall loss in other modularity
properties such as information hiding, independent extensibility, and
"traditional" modular reasoning.

What is wrong with having a module "invite" (or disallow) aspects (via
access control constructs, annotations, etc.) to advise it in a disciplined
way, as has been suggested by many others (including your ICSE paper).
True, the "invitations" themselves become a crosscutting concern and
obliviousness is compromised, however modular reasoning, information hiding,
and independent extensibility are preserved, as well as the ability to
modularize most (disregarding the invitations) crosscutting concerns.