Hi Doug:

Thank you for resending; I have somehow not seen your message before.

You have a strong argument for disallowing field overriding: we want symmetry 
between computed and stored parts.

So lets disallow field overriding in Demeter Java, although the
theory of strategies allows it. Indeed, the paper with Boaz allows multiple
inheritance (without conflicts), and concrete superclasses, i.e.,
it supports a very general OO model.

-- Karl

From dougo@ccs.neu.edu Thu Oct 16 17:01:18 1997
From: Doug Orleans <dougo@ccs.neu.edu>
To: dem@ccs.neu.edu
Subject: Re: overriding of instance variables

Karl, did you get this message?  I think we should disallow field
overriding.

------- start of forwarded message -------
From: Doug Orleans <dougo@ccs.neu.edu>
To: Karl Lieberherr <lieber@ccs.neu.edu>
Cc: dem@ccs.neu.edu
Subject: Re: overriding of instance variables
Date: Tue, 14 Oct 1997 13:32:03 -0400 (EDT)

Karl Lieberherr writes:
 > A = B.
 > B : C *common* <l> U.
 > C : D *common* <l> V.
 > D = .
 > U : V.
 > V = "v".
 > 
 > Main = .
 > 
 > Does Java allow this? Is the l of a D-object of class V?
 > 
 > Should Demeter/Java allow this too? Currently we get a compilation error.

Java allows this, which I didn't expect, but there are a few sectiosn
in the JLS explaining it.  It seems pretty non-intuitive, and
accessing the overridden part is awkward.  I vote for not allowing it,
because the same situation with methods is not allowed-- a method
cannot override a method with the same name but different return
type.  If we want to keep accessor-method/field as a one-to-one
relation, then we run into problems if we allow overriding of fields.

Regardless, it should not cause a compilation error.

--Doug
------- end of forwarded message -------