Hi Mira:

>From mira@informatik.uni-siegen.de Fri Dec  4 04:01:13 1998
>
>> Hi Mira:
>>   
>> Josh was pointing out a key difference between APPCs and aspects:
>>   
>> APPC: non-intrusive
>> aspect: intrusive
>> With an APPC we want to add behavior and with an aspect we want to
>> change behavior. Maybe we don't want to merge the two?
>
>
>> Josh thinks that APPCs should be distinct from aspects ...
>
>I still ... don't know about that. Let me give an example below.
>Please take my notes below with as they are -- fast thoughts
>written down.
>
>I'm reading a paper by Hedin and Knudsen:
>"Language Support for Application Framework Design"
>
>This is one of the papers you also wanted to discuss. The paper
>is more or less (I am not done with reading yet) about showing that
>certain constructs of the language BETA better support application
>design. One of this constructs is "method inheritance" or the so-called
>inner construct of BETA. David knows about that. Without going into
>explaining inner abstractly here is the example they give:
>
>Monitor: class {
>
> mutex: instance Semaphore;
> void entry() {mutex.P(); INNER entry; mutex.V() }
>
>}
>
>FIFOQueue: class Monitor {
>
>  L: list of Element; 
>  void put(e: Element) entry {L.insertLast(e)};
>  Element get() entry {return L.removeFirst()};
>
>}
>
>They argue that the inner mechanism of Beta allows 
>a finer-grained incremental modification: both methods
>put and get in the subclass FIFOQueue inherit the implementation
>in Monitor::entry():
>
>put(e: Element) entry {L.insertLast(e)}; 
>
>means the implementation of put will be the INNER of entry.
>The control flow is as follows when put is invoked on 
>a FIFOQueue object:
>
>first the more general method entry() will be executed
>it calls mutex.P() and then INNER. 
>INNER invokes the immediate more specific method -- in this
>case the implementation for FIFOQueue:put, i.e., L.insertLast(e) 
>will get executed.
>Finally, the control returns in the more general operation.
>
>The neat thing here is that the same generic behavior defintion
>(the one if the framework -- the class Monitor in this case):
>
>{mutex.P(); INNER entry; mutex.V() }
>
>is added (Josh would say modifies) to two methods in the application
>specific code. This remembered me on APPCs being applied different
>times to the same application. That's why I set down to write
>the same code above with the APPCs. This is the result:
>
>
>APPC Monitoring {
>  Interface {
>      //very simple -- only behavioral interface
>  MonitoredData {
>     * operation(*) } // * means don't care
>  Behavior { 
>    Semaphore mutex;
>    MonitoredData {
>     * mutually_Exclusive_Op (*) {
>          mutex.P();
>          operation(*);
>          mutex.V();
>          }
>     }
>  }
> }
>
>Alternatively (as in the project) 
>
>  Interface {
>      //very simple -- only behavioral interface
>  MonitoredData {
>     * operation(*) } // * means don't care
>  Behavior {
>    Semaphore mutex;
>    MonitoredData {
>     before operation { mutes.P(); }
>     after operation { mutex.V(); } } } } }
>
>Now assume tha application has:
>
>class FIFOQueue {
>
>  L: list of Element;
>  void put(e: Element) {L.insertLast(e)};
>  Element get() {return L.removeFirst()};
>
>}
> 
>Tha application has been designed for a non-concurrent context. Now we 
>want to add concurrency:
>
>FIFOQueue ::+ Monitoring with {
>                mutually_Exclusive_Op = {put, get}
>                operation = {put, get}
>              }
>
>Concurrency is an aspect. But I can see the above as composing two
>"components" -- the fifo and the monitoring component. The composition
>happens with the mapping.
>
>Thus, the APPC code achieves what the BETA code does. But I like the APPC 
>version better (how could it be different? :-)). I don't like the idea
>of making a FIFOQueue a special case of a monitor???!!! Furthermore,
>I think we can achive more than the BETA version. By being a 
>subclass of Monitor, FIFOQueue has a single semaphore. What if 
>I want to have several groups of methods being synchronized 
>on different semaphores? We can do that by reapplying the APPC
>different times with different mappings. 
>
>- Mira
>
>
You are saying that we can use an APPC Monitoring for defining
a synchronization wrapper for methods and when we have a class
that needs synchronization we can apply Monitoring to the class
and list the methods that need to be synchronized.

APPC Monitoring has a "parameter", namely the method to be wrapped.
I like this style of wrapper APPC and I am thinking now in terms
of two kinds of APPCs:

APPCs with one or more main-entries: augmenting APPCs
  they 
APPCs without a main-entry: enhancing APPCs

The enhancing APPCs take away behavior; the old behavior is no longer there.
Josh thinks of enhancing APPCs as aspects and not as APPCs.

In the mappings of  enhancing APPCs (or aspects) I would like to see
the possibility of specifying sets adaptively.
See the examples in the proposal:
http://www.ccs.neu.edu/home/lorenz/private/Codesign/proposal/

-- Karl