[PRL] AOP questions

[Matthias Felleisen]

On Mar 29, 2005, at 10:57 PM, Doug Orleans wrote:

> John Clements writes:
>> 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.
>
> I think AOP advocates might say that purely functional decomposition
> of a program isn't able to cleanly modularize some kinds of concerns,
> so it's better to have some other ways of looking at the program in
> addition to just functionally, such as classes or aspects.  Also, it's
> usually more about the level of organization above procedures, not so
> much how to model procedures themselves.  (Maybe it would help if you
> thought of an aspect as being like a functor/unit?  Have you read the
> Jiazzi papers?)

When we say "functional programming" we definitely include (1) 
functions, (2) datatype (and related things), and (3) modules with 
interfaces. Typically such a module looks like this:

(module foo mzscheme
   (provide new f g)
   (define-struct bar (content))

   (define (new an-int) (make-bar an-int))
   (define (f this) (bar-content this))
   (define (g this y) (new (+ (bar-content this) y))))

A client may look like this:

(module client mzscheme
   (require foo)

   (define instance1 (new 1))
   (define instance2 (g (new 2) 1))
   ...)

:-)

>
>> 2) "Join Points":
>> 	It appears to me that join points are not truly points, but are 
>> rather
>> contiguous subsequences.  I say this because of the existence of 
>> things
>> like "around" and "after" pcds, which don't make sense for a 
>> definition
>> of join points as single points in a program's execution.  Is this
>> fair?
>
> "around" and "after" are kinds of advice, not kinds of pointcuts.  Or
> maybe they sit somewhere in between.  They're sort of like
> combinators-- they say how to put together a join point with its
> advice.  (In Socrates, "around" is just a way of affecting advice
> precedence, and "before" and "after" are just macros for "begin" and
> "begin0".)
>
> --Doug
>
> P.S. Not all AOP methodologies are about dynamic join points,
> e.g. points in the program execution; some are about static join
> points, e.g. points in the program expression.  So I don't think it's
> accurate to say that "AOP insists on modeling evaluation as a series
> of execution states", because some AOP doesn't model execution at all.

It's fair to say that John should have written AspectJ (i.e., excluded 
HyperJ and friends).

-- Matthias