[aosd-discuss] Scope of AOP..

[Anil Pathak]

Newbie in this topic. I have some sort of stupid wish.

Can we tweak how the methods are called. May be instrumenting objects and  
method calls in runtime. And some sort of utility Class having function as

	CallStach [] getCallStack( Thread thread )

Where each elements in the CallStack[] represent the objects or the  
classes involved on calling finally the aspect code.

I suppose core of the topic is having acess to the scope to the method  
that generated the ( MyLogger.debug("Some debug statement"))




On Thu, 06 Apr 2006 01:53:57 +0545, Marc Eaddy <eaddy at cs.columbia.edu>  
wrote:

> 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.