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

[James Noble]

> 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.

so in a slightly more complex collection implementation - say a hashtable,
you can have auxiliary methods - not in the public API - that also maintain the invariant.
typically the method that takes a key and returns a pointer to an internal hash bucket, say.

public API methods are then implemented in terms of these methods.

My point here is (again) that this isn't a fields-vs-methods question.

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

the argument against private is that the whole of the subclass should protect the invariant.
(this assumes behavioural subtyping is implied by inheritance of course!)
so rather than just relying on private, you should verify the subclass properly maintains all invariants.

this argument relies on the principle that subclassing is a very tightly coupled relationship
if you want a looser relationship, build it yourself via composition.


(hmm this is actually one of the topics of the work Sophia & I are doing) 

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

what do we mean by "need"?
We can get most of the effect of "private" - other than "self" calls working properly - 
by putting private things into an enclosing lexical scope, JavaScript style. 

my objection to private is that it breaks the nice two stage model of request resolution
 --- locate then check accessibility --- because how we locate something depends on
whether it is private or not. 


on the other hand, it's hard to even associate behavioural invariants with our structural types,
so perhaps the whole question is moot?

James





On 5/07/2013, at 11:46 AM, Kim Bruce <kim at cs.pomona.edu> wrote:

> 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
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core