[aosd-discuss] Scope of AOP..

[Sahil Thaker]

Hi Marc,

 > Our solution [1] was to use "statement annotations" to express the
logging
> concern:
> 
> someMethod() {
> 	@Log("Some debug statement")
> 	...blah blah...
> 	@Log("Another debug statement")
> 	...blah blah...
> }
> 	I think part of the problem is the obliviousness requirement.
Why
> not allow the base programmer to not only be aware of aspects, but to
also
> use them ubiquitously to implement crosscutting business logic and
> "functional" requirements?

How is this different to making a function call?
 

> 	I think part of the problem is the obliviousness requirement.  

It is possible to have heterogeneous cross cuts while being oblivious,
you will just have many of them, e.g one for each unique log statement.
An advantage may be that logging module is more cohesive.
 

When I say oblivious I mean oblivious from the point of view of
code-base, not from design. joint points don't appear magically, you can
get lucky sometimes and AspectJ's elaborate JPM makes this more likely,
however in most non-trivial cases you must design them, and in your
design you will consider what the a potential aspect will see, what will
it change, etc. Hence, obliviousness is not a "requirement" of aop per
se. 

This arguments leads back to the point you made: "Why not allow the base
programmer to use aspects?" (since the designer will have to be aware of
them anyway)

And in that case, would it still be AOP?








> -----Original Message-----
> From: discuss-bounces at aosd.net [mailto:discuss-bounces at aosd.net] On
Behalf
> Of Marc Eaddy
> Sent: Wednesday, April 05, 2006 3:09 PM
> To: 'Atul A Gohad'
> Cc: discuss at aosd.net; 'Alfred V. Aho'
> Subject: Re: [aosd-discuss] Scope of AOP..
> 
> Hi Atul,
> 
> 	Logging (as opposed to Tracing) is a good example of a
> "heterogeneous concern" because it is located at arbitrary locations
in
> code
> and requires user-defined context-dependent log messages.  People have
> tried
> and failed to modularize logging using AspectJ.  This has become known
as
> the "logging problem", but it actually applies to any heterogeneous
> concern.
> Our solution [1] was to use "statement annotations" to express the
logging
> concern:
> 
> someMethod() {
> 	@Log("Some debug statement")
> 	...blah blah...
> 	@Log("Another debug statement")
> 	...blah blah...
> }
> 	The nice thing about this approach is that the method and class
name
> that you mentioned, as well as file name, line number, etc., are
exposed
> as
> context to the advice so the programmer doesn't have to type these in
> explicitly.  Unlike a macro or function call, the statement annotation
can
> be processed at any time or could be completely ignored (say, if
logging
> is
> disabled).  In addition, the logging concern can be integrated with
normal
> method call tracing because they both can use the same AOP
implementation.
> 
> 	Along with [2], I believe that the concerns that we care the
most
> about in a software system, e.g., the business logic, are mostly
> heterogeneous.  If AOP is only good at modularizing homogeneous (aka
> "operational", "orthogonal", and "nonfunctional") concerns, e.g.,
tracing,
> security, caching, I think it is falling short of its potential.
> 
> 	I think part of the problem is the obliviousness requirement.
Why
> not allow the base programmer to not only be aware of aspects, but to
also
> use them ubiquitously to implement crosscutting business logic and
> "functional" requirements?
> 
> Cheers,
> 
> \\Marc
> 
> [1] M. Eaddy and A. Aho, "Statement Annotations for Fine-Grained
> Advising,"
> In Submission, April 2006.  Url:
> http://www1.cs.columbia.edu/~eaddy/publications/Position%20Paper%20-
> %20State
> ment%20Annotations%20for%20Fine-Grained%20Advising.doc
> 
> [2] M. Trifu and V. Kuttruff, "Caputuring Nontrivial Concerns in
> Object-Oriented Software," In Proc. of the Working Conference on
Reverse
> Engineering (WCRE'05), November 2005.
> 
> > -----Original Message-----
> > From: Atul A Gohad [mailto:agohad at in.ibm.com]
> > Sent: Wednesday, April 05, 2006 6:16 AM
> > To: discuss at aosd.net
> > Subject: [aosd-discuss] Scope of AOP..
> >
> >
> > What's the scope of AOP? Is it just the injection of code?
> >
> > Can we use AOP to modify / evolve the way concern is actually
> > implemented.
> >
> > How is something like below acheived using AOP, across the
> > components?
> >
> > someMethod() {
> >           MyLogger.debug("Some debug statement");
> > }
> >
> > Intention is to modify the above debug method so as to accept
> > additional parameters:
> >
> > someMethod() {
> >         MyLogger.debug(className, methodName, "Some debug
> > statement");
> > }
> >
> > Thanks,
> > Atul.
> >
> >
> >
> 
> 
> __________________________________________________
> AOSD Discuss mailing list    -    discuss at aosd.net
> To unsubscribe go to http://aosd.net
> 
> Check out the AOSD.net Wiki: http://aosd.net/wiki