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

[Andrew P. Black]

Folks,

I've been thinking more about the discussion that we (James, Andrew, Michael and Kim) had yesterday (at ECOOP) about visibility of defs and vars in objects.

I'm sympathetic to the theoretical principle  that annotations should only restrict otherwise legal programs, and not make otherwise incorrect programs work.  However, I also believe in encapsulation as one of the core values of OOP.   Making defs and vars in objects public, just so that we can use annotations to restrict access to them, seems to fly in the face of encapsulation.  We have said many times that programs that "do the right thing" should be shorter than programs that don't.  Most of the time, access to variables and constants defined in an object should be restricted to the methods in that object.   So this should be the default.

I don't have a problem with the default for methods being public.  That's the reason to have a method: so that clients can request it.

I also like to think of the "publiclyReadable" annotation (or whatever we call it) as generating a method.  I know that there is an alternative view in which variable access itself can be dynamically bound, an in Self and in Java.  But I think that the "generated method" view is easier to explain to novices and easier to understand.  The rules for method lookup are then simple and uniform.   Maybe the objection to annotations liberalizing programs could be overcome by replacing this particular annotation by a new keyword, such as field or feature.  Maybe "is method" is better than "is publiclyReadable"

I don't yet understand why making variable and constant access lexical makes the name resolution rules any more complicated than they would be without such lexical access.  We already have lexical access to parameters and temporaries, both in the current scope and in lexically enclosing scopes.  We therefore already need rules that disambiguate between requests of methods and access to defs.  Why is the access to x in the example below any more complicated than the access to p?

    object {
        method new(p) {
	    object {
                def x = 56
                method doit(q) {
                    (p + x) ^ q
                }
            }
        }
    } 

In the following example, is the use of p in doit a method request or a use of the parameter of new?   We have to have a rule about this, and we have to teach it, and it's embarrassing that the language is so complicated that I'm not sure what it is!   But whether x is always dynamically or always lexically bound won't fix this problem.  The only "fix" would be to get rid of lexical binding altogether, including in blocks that capture their environment, and including parameters.  None of us thinks that this would be a good idea!

    object {
        method new(p) {
	    object {
                def x = 56
		method p {1}
                method doit(q) {
                    (p + x) ^ q
                }
            }
        }
    } 

I'm very interested in talking about this more and finding out why the changes that you proposed would help.

	Andrew

			    
		
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20130702/63a2f8b1/attachment.html>