A quick note before the plane leaves ...

I agree that Mira's syntax is much better than mine for the new use
of strategies which she proposed. I am afraid that this message might
be too short, so Mira will explain more.

The new "pattern"

Adjuster ADJ (Strategy s =
				 {-> {Class1 Class2} Target}) {
	Class1{
	  void event1() {
	    before (@ // ... doSomethingBefore1 .. @)
	  }
        ...

is something really useful which we did not have before.
The strategy reveals the rough structure of the collaboration 
and the before and after (and something like around) say
how the classes are extended in a coordinated way. So it
is like strategically controlled class extension.

Mira and I also discussed that adjusters and visitors are
very close but we don't have a common name yet: any ideas
how the superclass of visitor and adjuster should be called?

-- Karl

===========
From mira@ccs.neu.edu Wed Jan 21 19:42:12 1998

Well, this is my intuition about the meaning of the code, Karl has written
above. Karl could give the original description.

Anyway, the collaboration between instances of Class1 and Journal via the path 
between Class1 instances and Journal instances is central for the behavior
encoded by this pattern.
The idea of modeling this pattern by means of adjusters parametrized by strategies
is to make explicit the fact that responsibility is passed through the path 
mentioned above - in the strategy. I would have written the code as follows:

Adjuster JOURNALIZER (Strategy s =
				 {-> {Class1 Class2} Journal}) {
	Class1{
	  void event1() {
	    before (@ // ... doSomethingBefore1 .. @)
	  }

	  void event2(Par p) {
	     before (@ // ... doSomethingBefore2 .. @)
	     after (@ // ... doSomethingAfter2 .. @)
	  }
	 }

	Class2 { ... }

	Journal {
	    event1() { mystructure.register("Class1.event1" ); }
	    event2(Par p) { mystructure.register("Class1.event2", p); }
	  }
 }

Assuming the following class graph:

Class graph:

Class1 = ... <admin> InfoManagement.
InfoManagement = ... <journal> Journal.
Journal = // ... whatever

the generated java code would look like:

	Class1 {

	  InfoManager admin;

  	  void event1() {
		// ... doSomethingBefore1 ...
		admin.event1();
		}

	  void event2() {      
		  // ... doSomethingBefore2 ...
		  admin.event2();
		   // ... doSomethingAfter2 .. 
		   }

	InfoManagement {

	  Journal journal;

	  void event1() {
		journal.event1();
	  }
	  ...

	  void event1() {
		journal.event1();
	  }

	  }
		

        Journal {  
		    event1() { mystructure.register("Class1.event1" ); }
		    event2(Par p) { mystructure.register("Class1.event2", p); }
	  }
	}


Note:

1- I don't use "at". I definitely agree with Doug in the following:

Doug Orleans writtes:
>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
>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

2- Code like the following found in Karl's "program" are omitted:

  KL> do s { //ommitted during
  KL>      at s.target {
  KL>        when-visiting {host.event2(p);}}}

 I think this is redundant. Since, the strategy is specified as a parameter of
 the whole adjuster, what has to be done when at target (= the 
 class valued variable Journal) is already encoded by the code for event1 and 
 event2 in Journal.

3- I use "before" and "after", agreeing with Doug:

Doug Orleans writtes:
>Again, I think we should keep the "before" and "after" keywords, 

instead of next -- however, for the case when "next()" denotes the code 
that performs the traversal.