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

[James Noble]

>  I also believe in encapsulation as one of the core values of OOP.

So do I! 

> variables and constants defined in an object should be restricted to the methods in that object.   So this should be the default.

I see this as a question about defaults, rather than a question about the underlying "evaluation model"

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

I think we all want method lookup rules to be simple and uniform.
The question is if we also have *other* rules that describe variable/field lookup,
or if we can lookup/bind everything with once set of rules.

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

because before you can know whether a request "x" will be bound lexically or dynamically,
you have to look for the definition of "x" and see whether it is a var/def or a method.

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

Because p (& q) are defined in lexical scopes (or lexical contexts) - they can *only* be resolved lexically.  x id in an object scope, it could can be resolved either lexically or dynamically - and in the context of inheritance, the semantics are different. 

>     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
> 
> 			    
> 		
> _______________________________________________
> 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/20130703/1a3c9ae9/attachment.html>