[Grace-core] Visibility of variables and constants in Objects

Kim Bruce kim at cs.pomona.edu
Fri Jul 5 02:46:16 PDT 2013


Marco & I had a brief discussion about "private" this morning. He reminded me that an important use of private is to ensure that invariants can't be broken by subclasses. Let aList be a class representing a list via a reference to the head (of a linked list) and a size field.  An invariant we would like to preserve is that the size field corresponds to the actual size of the list. Normally these would be declared to be private, with a public method that adds an element to the list after position I, for example. That method would insert the element into the linked list and update size. Similar for deletions. Because size and the head to the list are private, they will not be directly accessible to subclasses. As a result the subclasses will not be able to override or add methods that will break the invariant. 

If we have only confidential or public for fields ,then we cannot protect the invariant as the instance variable (and the generated methods) are accessible. Thus we can override the add method to increase size incorrectly.

I don't see an easy way around this difficulty, and I believe we will want to protect invariants. Did I miss anything?


PS. Mario does not agree that we need "private."


Sent from my iPad

On Jul 3, 2013, at 11:21 AM, "Andrew P. Black" <black at cs.pdx.edu> wrote:

> 
> On 3 Jul 2013, at 01:30 , Michael Homer wrote:
> 
>> Access to the same thing follows two different rules depending on how
>> you annotated it.
> 
> I think that this nicely captures the difference in viewpoint.  Michael (and James, I think) view defs and vars in objects as being fundamentally different from defs and vars elsewhere in the language: like methods, such defs and vars are "features" of the object, and all "features" should be accessed uniformly.
> 
> Kim and I view defs and vars in objects to be just like defs and vars in other places.  The annotation on them generate methods, and those generated methods are treated like other methods.
> 
> As to the defaults for these generated methods being different from the defaults for explicit methods, Michael is right: we can't remember what the rules are, and nor will the students.  That's why I've started writing is publiclyReadable, is confidential, is confidentiallyReadable, etc, so that the annotations are explicit and clear, and there is nothing to memorize.
> 
> If we were to agree on a language change for def and var access in objects, so that they are bound like methods rather than like other defs and vars, then we should also change the keywords. 
> 
> 	Andrew
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130705/27bb6f68/attachment.html>


More information about the Grace-core mailing list