Hi Shriram: there is a more abstract view of Demeter/Java than the one I presented. This view is in the context of aspect-oriented programming (AOP). http://www.ccs.neu.edu/home/lieber/AOP.html In addition to the adaptive program P and class graph G, Demeter/Java takes as input aspect descriptions A1, ... ,An, currently only: COOL for the synchronization aspect RIDL for the remote invocation aspect The overall goal of Demeter/Java is to avoid code tangling. Traversals and visitors untangle structure and behavior and COOL untangles synchronization from behavior and RIDL untangles remote invocation from behavior. Adaptive Programming is a special case of Aspect-oriented Programming where graphs and traversal strategies are used in behavior or aspect descriptions or both. RIDL also uses traversal strategies to express selective object marshalling. -- Karl >From dougo@ccs.neu.edu Sun Feb 22 23:47:58 1998 >Date: Sun, 22 Feb 1998 23:47:56 -0500 (EST) >From: Doug Orleans >To: Karl Lieberherr >Subject: Re: Question about Demeter > >Karl Lieberherr writes: > > Hi Shriram: > > > > You are quite close. > > > > The input to Demeter/Java consists of: > > > > 1. A class graph G (similar to a UML class diagram), > > also defining a context-free grammar. > > 2. An adaptive program P consisting of: > > - Traversal specifications (called strategies) > > - Visitors, specifying the non-traversal operations to perform > > before, after or around each node or edge. > > - Glue code which links traversals and visitors. The glue code can take > > different forms by instantiating the visitors manually or by using > > so called adaptive methods which instantiate the visitors for you. > >Don't forget the COOL and RIDL aspects! :) > Date: Sun, 22 Feb 1998 22:49:00 -0600 (CST) From: Shriram Krishnamurthi I wanted to make sure I had understood the abstract view of Demeter. Your message gave me just the information I need. Thanks! 'shriram