Hi Doug:

>If so, it seems like you want to
>add two things:

>  1. parameterization, i.e. you can pass a strategy in and refer to
>     its parts with class-valued variables, rather than hardwiring
>     them.
>  2. encapsulation, i.e. packaging the two traversals together,
>     arranging the code according to class rather than function, and
>     (potentially, but not in this example) sharing local data and
>     functions across multiple traversals.

You give a summary which matches exactly with my understanding. The adjusters are really
about packaging traversals. Do you have an example where traversals want
to share data and functions?

-- Karl


>From dougo@ccs.neu.edu Sat Feb  7 01:39:55 1998
>Date: Sat, 7 Feb 1998 01:39:50 -0500 (EST)
>From: Doug Orleans <dougo@ccs.neu.edu>
>To: Mira Mezini <mira@ccs.neu.edu>
>Cc: dem@ccs.neu.edu
>Subject: Re: more integration
>
>I think I'm slowly starting to grok this example...  Let me try to
>restate what is going on.
>
> > The pattern we have here is as follows: 
> > "any time event1 and event2 are invoked on an object of Class1 (as well as
> > certain other methods on objects of Class2 which are omitted above) messages
> > with the same name are invoked on an instance 
> > of Journal that is part of the structure of Class1's instance on which 
> > event1 and event2 are being invoked. In other words, invokations of 
> > event1 and event2 on Class1 are registered in objects of Journal"
> > 
> > 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); }
> > 	  }
> >  }
>
>This code is defining two new methods on [the class-valued variable]
>Class1, event1() and event2(), each of which performs a traversal to
>the Journal class and calls mystructure.register(...).  In the current
>version of Demeter/Java, this would be written as:
>
>Class1 {        // No name-mapping yet, assume there is a class
>		// called "Class1".
>  traversal toJournal(JournalVisitor) { to Journal; }
>  void event1() = toJournal {
>    before Class1 (@ /* ... doSomethingBefore1 .. */ @)
>    before Journal (@ mystructure.register("Class1.event1"); @)
>  }
>  void event2(Par p) = toJournal {
>    before Class1 (@ /* ... doSomethingBefore2 .. */ @)
>    after Class1 (@ /* ... doSomethingAfter2 .. */ @)
>    before Journal (@ mystructure.register("Class1.event2", p); @)
>  }
>}
>
>Is this roughly what you intended?  If so, it seems like you want to
>add two things:
>
>  1. parameterization, i.e. you can pass a strategy in and refer to
>     its parts with class-valued variables, rather than hardwiring
>     them.
>  2. encapsulation, i.e. packaging the two traversals together,
>     arranging the code according to class rather than function, and
>     (potentially, but not in this example) sharing local data and
>     functions across multiple traversals.
>
>Do I have this right?  Is there more to it that I'm missing?
>
>--Doug
>