Re: Scope of AOP..

Hi Shahil,

	Good comments.  My responses are below: 

> 
> As Pascal has suggested there are trivial workarounds to 
> these using existing approaches, including point 3 - function 
> call would be synchronous but you would have a logging module 
> that executes the actions asynchronously and returns from the 
> call without wait. And one could use design patterns, flags, 
> or simple metaprogramming approaches to select/deselect 
> functionality, just as cleanly as you select/deselect aspects 
> at weave time. 
> 

I want a unified AOP solution rather than have some crosscutting concerns
implemented using OOP and some modularized using AOP.

>
> I'm not saying it is not a good idea to have these forms of 
> annotations, but if these can be equated to explicit function 
> calls, are you still using AOP to modularize it?
>

I see these "annotation calls" as the base code residue needed by the AOP
implemention of the crosscutting concern.

>
> How is it 
> different to modularize logging using your AOP approach than 
> doing the same with OO modularization?
>  

I'd like to modularize crosscutting concerns in a uniform way, e.g., using a
unified AOP approach.  Also, some AOP languages (AspectJ) provide extra
niceties like jp context exposure, aspect instantiation, and flexible and
optimized advice invocation, which the base language doesn't provide.

> 
> 
> > Attempts at completely modularizing the logging concern 
> using standard 
> > AspectJ, for example, have not been very successful:
> > 
> > 1. the resulting pointcuts were very fragile;
> > 
> > 2. the pointcuts were not powerful enough to advise the exact join
> points
> > needed; and
> > 
> > 3. a separate advice is needed for each unique message 
> resulting in a
> lot
> > of
> > redundant code.
> 
> I Agree.
> 
> 
> > In short, what you gain in modularity, you lose in locality and 
> > explicitness.  Using our approach, the aspect only modularizes the 
> > portions of the logging concern that can be modularized 
> /effectively/: 
> > the
> logging
> > policy, what jp context to include in the log message, 
> when/where/how 
> > messages are logged, etc.  The portion of the logging concern that
> cannot
> > be
> > modularized effecitvely, e.g., the user-defined log message and
> location
> > in
> > the source code, are expressed using (local and explicit) statement 
> > annotations.  We believe this is the proper balance for the logging 
> > concern.
> Ok.
> 
> > What you seem to be implying is that the base programmer is aware of
> the
> > aspects in the design but the base code is oblivious, i.e., the base
> code
> > does not need to be "prepared" in order to support the aspects.  How
> is
> > this
> > an improvement?  Since the base programmer is already aware of
> aspects,
> > what's wrong with "using them" explicitly in the base code? 
> 
> I agree; if you must be implicitly designing the joint 
> points, why not make it explicit? Certainly there are times 
> when obliviousness does not serve well.
> 
> My question to the AOP community is this: If we do what you 
> have suggested here - make joint points explicit through 
> annotations, function calls, macros etc, is it still considered AOP?
> 

Very good question!  The goal of AOP is to separate crosscutting concerns.
If the final result of annotations, etc. is that the system is more modular
and decoupled, I think the answer is yes, it is AOP.


__________________________________________________
AOSD Discuss mailing list    -    [email protected]
To unsubscribe go to http://aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki