[PRL] AOP questions

[John Clements]

On Mar 29, 2005, at 10:00 PM, Pengcheng Wu wrote:

>
>
> On Tue, 29 Mar 2005, John Clements wrote:
>
>> I have several questions, but I'm stating them as assertions. Anyone
>> who can clarify my thinking or correct me, please please do so.
>>
>> 1) Model of computation:
>> 	AFAICT, AOP insists on modeling evaluation as a series of execution
>> states.  AOP then defines the application of advice+pcds to a program
>> as a modification of this series of execution states.  That is, AOP is
>> modeled as an execution monitor that watches a series of execution
>> states, and interrupts execution when a piece of advice applies to the
>> current execution state.  This seems sad, to me, because abstraction 
>> as
>> functional programmers understand it is all about modeling procedures
>> as relations from inputs to outputs, not as sequences of execution
>> states.  This model seems like a giant step backward from true
>> abstraction back toward FORTRAN-style subroutines.  Am I just crazy?
>
> This is a "symptom" of imperative programming, isn't it? So it is not
> really AOP's fault. I think AOP's idea is orthogonal to functional
> programming or imperative programming. For example, I can well imagine 
> AOP
> is used in functional programming's spirit, in which you only have
> 'around' advice that just change the original base functions' mappings
> from inputs to outputs. But of course this doesn't necessarily mean AOP
> is a good thing for this scenario. Just my 2 cents.

Yes and no.

Yes: I can imagine an "AOP" that is "functional" in the sense that you 
can specify certain functions as the recipients of advice, and advice 
can remap the inputs or the outputs or replace the function entirely.

No:  the big thing that's missing in this "functional AOP" model that I 
think most AOP-ers find central to AOP is the idea of CFLOW-like 
pointcuts, that don't have to do with replacing one function with 
another but rather with replacing one dynamic execution path with 
another.  That is, they want their join-point matching to extend beyond 
the static context of the event being matched, so that they can say 
things like "any call to method m() that's within the dynamic extent of 
a call to method p()".

Of course, in the presence of mutation and global rewriting, it's hard 
to really draw a distinct line between these two.

john