Hi Doug:

>I'm sorry to be asking so many questions, but I'm just having a hard
>time grasping what you've been working on for the last few weeks, and
>I suspect it's pretty important.

It is good you ask those questions. They really help. 

What we are trying to do is to integrate a bunch of useful ideas
into the Demeter/Java world: Mezini's Rondo ideas, Batory's
mixin layers, CLOS before and after and around methods and 
Holland's contracts. All those works have something to do with modifying
groups of classes and that is also the main theme in the current
Demeter/Java.

The first example below is an abstraction of (proposed by Mira):


Adjuster PERFORMING_TRANSACTIONS (Strategy s = {-> Account Logging}) {
  at Account {
    void deposit(Amount a) {
      do s { // omitted during
	at s.target {
	  when-visiting {
	    host.deposit(a);
	  }
        }
      }
          // maybe we can use some syntactic sugar here
	  // do s is a statement added to the OO language 
      balance = balance + a;
    } 
    void withdraw(Amount a) {
      do s { //omitted during
	at s.target {
	  when-visiting {
	    host.withdraw(a);
	  }
        }
      }
      balance = balance - a;
    } 
  }
  at Logging {
    deposit(Amount a) { mystructure.register("deposit", amount); }
    withdraw(Amount a) { mystructure.register("withdraw", amount); }
  }
}

which is more intuitive.

>From dougo@ccs.neu.edu Mon Jan 19 22:37:33 1998
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>Cc: dem@ccs.neu.edu
>Subject: Re: more integration
>
>Karl Lieberherr writes:
> > The JOURNALIZER pattern is described by an adjuster as follows:
> > 
> > Adjuster JOURNALIZER (Strategy s = 
> >   {-> {Class1 Class2} Journal}) {
> >   at Class1 {
> >     void event1() {
> >       do s { // omitted during
> > 	at s.target {
> > 	  when-visiting {host.event1();}}}
> >           // maybe we can use some syntactic sugar here
> > 	  // do s is a statement added to the OO language 
> >       next(); 
> >     } 
> >     void event2(Par p) {
> >       do s { //ommitted during
> > 	at s.target {
> > 	  when-visiting {host.event2(p);}}}
> >       next();
> >     } 
> >   at Class2 { ... }
> >   }
> >   at Journal {
> >     event1() { mystructure.register("Class1.event1" ); }
> >     event2(Par p) { mystructure.register("Class1.event2", p); }
> >   }
> > }
>
>I'm having trouble figuring out what this syntax means.  Can you
>suplpy the Java code that this would be translated into?  Also, a
>better indentation would help, as would lining up the braces...

The Java code would simply navigate from Account to Journal
and update the journal. Let's discuss in the seminar.

>
>Also, since the strategy goes from { Class1, Class2 } to Journal, this
>means every object in the object graph has to have a pointer to the
>journal object?  (Or some path to it.)  And does this mean you can
>only use the Journalizer with two classes?

Yes, we must have those paths. We would like to express the pattern
with any number of classes but for simplicity I expressed it for two.

>
> > We already have adjusters in Demeter/Java:
> > 
> > C {
> >   int f() to Z (V);
> >   }
> > 
> > is an adjustment which extends only class C with f.
> > 
> > We are going to write this as:
> > 
> > Adjuster Adj {
> >   at C {
> >     int f() to Z (V);
> >   }
> > } 
> > 
> > modify by Adj; // will modify class graph by adding f to C
>
>I think this is a good extension, and gives us a way to modularize
>methods across classes.  A minor syntax change would allow us to be

Great you like this. What we did above was applying this extension
several times and factoring out the strategy.

>backwards compatible with the way Demeter/Java is now: remove the "at"
>keyword (it seems superfluous), and assume that anything outside of an
>adjuster is in some "default adjuster", similar to the "default

A good idea to stay as close to Demeter/Java as possible.

>package" in Java.  Or perhaps each file would have its own default
>adjuster, but that's probably not much different if there's no way to
>refer to the default adjusters.
>
> >       void insert (EleType el) {next.insert(el); count++;}
> >       void erase (Node node) {next.erase(el); count--;}
>
>Again, I think we should keep the "before" and "after" keywords, in
>which the call to next is implicit.  Also, it might be better to have
>the call to next be like the current around methods, i.e. a thunk
>object which has only one method, apply().  Then the user won't have
>to worry about the name of the method, or the arguments.

Let's discuss with Mira. I am in favor of keeping before
and after for visitor composition. It it probably makes sense
to use before and after also for adjuster composition.

>
> > Visitor V1 (Strategy s) {
> >   during s {
> >     at D {
> >       when-visiting { ... }
> >     }
> >     at E {
> >       when-visiting { ... }
> >     }
> >   }
> > }
>
>I'm still not sure what the purpose of the "during s" phrase is.  What
>else could go at the beginning of a visitor body?  Maybe we could get
>rid of the outermost curly braces?  E.g.
>
>    visitor V1(Strategy s) during s {
>        ...
>    }
>

Yes, that is a very good idea.

> > We view adjusters and visitors as the key building blocks of 
> > implementations of aspect languages.
> > 
> > We have collaboration between adjusters:
> > next.f() calls f in the next adjuster.
> > 
> > We have collaboration between visitors:
> > next_visitor.get_state() gives current state of next visitor
> >   Mitch proposed this name over next.result()
> > 
> > next(): calls code of next visitor.
>
>This is also confusing.  What is the type of next?  next_visitor?
>What other methods (or pseduo-methods) are available?
>

Let's discuss this also with Mira. Currently we have simplified the 
situation by only allowing a composition of a linear sequence 
of adjusters and visitors. next or next_visitor points to the
next building block in the list.

>
>I'm sorry to be asking so many questions, but I'm just having a hard
>time grasping what you've been working on for the last few weeks, and
>I suspect it's pretty important.
>
>--Doug
>

-- Karl