Hi Johan:

Let's see how we can resolve this. I bring in some precise terminology from
the paper with Boaz. Maybe you have found a bug in the paper?

>From johan@ccs.neu.edu Fri Oct 17 13:44:10 1997
>From: Johan Ovlinger <johan@ccs.neu.edu>
>To: lieber@ccs.neu.edu
>CC: lieber@ccs.neu.edu, dem@ccs.neu.edu
>Subject: Re: overriding instance variables
>
>Karl:
>  One point in the paper with Boaz is that
>  without loss of generality we can do all our work related to traversals
>  on simple class graphs. I believe in that reduction consisting of three steps:
>  eliminate concrete super classes, common parts and inheritance chains.
>  Do you?
>
>The sticking point is flattening. If we flatten all common parts down
>to the concrete classes 
>  ( w/o renaming them, that is. If we rename them, then shadowing is a
>    non issue and the problem is solved. Can we rename them? Let us call
>    the semantics with renaming allowed A and the semantics with renaming
>    disallowed D. )
>                        and thereby remove from the flattened
>representation a shadowed part that would have been traversable in the
>original object graph (albeit with a bit of hassle , but nonetheless),
>we have a smaller set of possible traversals for semantics D than in
>the original case. Hence the WOLG claim does not hold for D. 

I don't see it. You say that for a strategy SS and a class
graph G, SS[G,N] != SS[D-Flatten(G),N]. The paper states that:
SS[G,N] = SS[D-Flatten(G),N]. In other words,
flattening without renaming does not change the concrete paths
nor the traversals at the object graph level. 
SS is defined in definition 4.4.
I agree that
SS[G,N] != SS[A-Flatten(G),N], since the renaming during flattening changes
the objects.

>
>If we allow parts to be renamed upon flattening, then I believe that
>the same set of traversals is possible as for the original calse, and
>thus I believe the the claim of WLOG holds for A.
>
>Renaming is a hassle. Nobody wants to go through the java code and
>rename variable references (and what if the parts are public-
>yuck!). How to reconcile this? Luckily, by restricting the set of
>input class graphs to the set where no part is overridden (even at the
>same type) by a subclass, we remove the case where the D semantics
>were at odds with the WLOG claim. It is easy to see that with this
>restriction,  A == D. 
>
>I assume that the paper with boaz has assumed no overriding. 

The paper with Boaz assumes no multiple inheritance conflicts but
it allows overriding within the same ancestry.

>
>Johan
>

-- Karl