Hi Mira:

>From mira@ccs.neu.edu Mon Jun 29 15:36:00 1998
>Subject: Re: interface class graph
>To: johan@ccs.neu.edu (Johan Ovlinger)
>Date: Mon, 29 Jun 1998 15:35:07 -0400 (EDT)
>Cc: lieber@ccs.neu.edu (Karl Lieberherr), mira@ccs.neu.edu,
>        dougo@ccs.neu.edu (Doug Orleans),
>        jayantha@ccs.neu.edu (Joshua C. Marshall)
>
>Hi Johan and Karl:
>
>It seems to me that you are actually talking about the same thing and that
>only the terminology you use is different.
>
>I agree with Johan that there is a distinction between (a) the class graph
>interface which describes what we expect from the class graphs to
>satisfy in order for the APPC to work and (b) the strategies used
>within the APPC which are written to the class graph interface and that
>describe how to traverse an object structure.
>
>If we make the analogy to the terminology used today in Dem/Java, the
>class graph interface is a "counterpart" of the class disctionary, while
>the strategies are counterparts of the traversal strategies now written to
>a class graph interface rather than to a concrete class dictionary. 
>
>Karl means pretty much the same thing, I believe. Except that he uses the

yes, I do.

>term "strategy type". I think it is a good idea to write class graph
>interfaces in the interface part of an APPC by using a notation like that
>of class dictionaries. Thus, the interface part of an APPC contains 

Yes. We have come several times to the conclusion that strategy graphs
and class dictionaries should be integrated.
Strategies probably should talk about syntax so that a strategy graph
defines a nice family of class dictionaries and not only a family
of class graphs. Let's think about this.

>
>(a) minimal requirements on the structure of (a subpart of) class
>    dictionaries to which the APPC can be applied. This is  the
>    class graph interface written in a notation similar to that of
>    class dictionaries.
>
>(b) minimal requirements on the behavior of (a subpart of) class
>    dictionaries to which the APPC can be applied. This is the part that 
>    declares the interfaces we expect by the classes mentioned in the 
>    class graph interface.
>
> 
>The behavior of the APPC is then written to this interface.
>As Karl says, when a specific class graph
>is given, we have to personalize only once the class graph interface 
>(strategy type) and that will carry over to the strategies used
>internally.
>
>Karl says:
>
>> We will need to work out a precise definition of the family
>> of class graphs defined by a strategy type.
>
>Johan was in my office, and we kinda mentioned that maybe ... graph
>homeomorphism could be used for defining the family ... Just an idea ...
>

A very good idea. Let me try:
A class graph G is in the family of a strategy graph S
if S is a "homeomorphic subgraph of G".
We need to work out some details like name map and sources and targets
but this looks like a good idea (we have to watch the complexity of checking).

The interface is sandwiched between:

A family of class graphs homeomorphic to the interface and
a family of strategy graphs homeomorphic to the interface.

>
>- Mira
>

-- Karl

>---------- here starts Karl's mail to Johan -------------
>
>Hi Johan:
>
>you are talking about the interface of an APPC to a class graph.
>That interface expresses constraints which the class graph
>must satisfy for the APPC to work. Those constraints are of
>different forms but a very important kind of constraints are
>path existence constraints. Those constraints come from the strategies
>used internally by the APPC. Now, instead of putting all those strategies
>into the interface of the APPC I propose that we consolidate them
>into one strategy (a strategy type).
>
>The reason for the consolidation is that when a specific class graph
>is given, we have to personalize the strategies to that class graph.
>It is much easier to personalize only once the strategy type
>and that will carry over to the strategies used internally.
>
>Strategy graphs have now subclass edges and abstract classes.
>
>How does this justification sound? Maybe it sounds a little strange
>the blurring of class graphs and strategy graphs but it makes things
>simpler.
>
>-- Karl
>
>>From johan@ccs.neu.edu Sun Jun 28 21:00:58 1998
>To: Karl Lieberherr <lieber@ccs.neu.edu>
>cc: dougo@ccs.neu.edu, johan@ccs.neu.edu, jayantha@ccs.neu.edu,
>        mira@ccs.neu.edu
>Subject: Re: interface class graph
>From: Johan Ovlinger <johan@ccs.neu.edu>
>
>I think interface class graphs are best described in terms of
>classes/intefaces. In short, for the vary same reason why we just
>don't use strategies for every thing; both class graphs and
>traversals.
>
>In more length, there are two main arguments for this:
>
>1) The role of a strategy is to talk about the object graph, but
>   the role of the interface graph is to give a different view of the
>   class graph. Thus, using strategies as interfaces makes it
>   difficult to talk about abstract classes, which are a very
>   important aspect of the class graph.
>
>2) Just because we use the same convienent graph notation for
>   strategies and class graphs, the interpretation of the two is quite
>   different. I think it is obvious that we stick to the same notation
>   for describing interface graphs, (in my terminology "module
>   interfaces"). The the sematics of the module's interface are much
>   closer to that of class graphs than strategies.
>
>Johan