<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><blockquote type="cite"><div> I also believe in encapsulation as one of the core values of OOP. </div></blockquote><div><br></div>So do I! <div><br><blockquote type="cite"><div>variables and constants defined in an object <i>should</i> be restricted to the methods in that object. So this <i>should</i> be the default.</div></blockquote><div><br></div><div>I see this as a question about defaults, rather than a question about the underlying "evaluation model"</div><br><blockquote type="cite"><div>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. </div></blockquote><div><br></div><div>I think we all want method lookup rules to be simple and uniform.</div><div>The question is if we also have *other* rules that describe variable/field lookup,</div><div>or if we can lookup/bind everything with once set of rules.</div><div><br></div><blockquote type="cite"><div>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. </div></blockquote><div><br></div><div>because before you can know whether a request "x" will be bound lexically or dynamically,</div><div>you have to look for the definition of "x" and see whether it is a var/def or a method.</div><br><blockquote type="cite"><div>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?</div></blockquote><div><br></div><div>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. </div><br><blockquote type="cite"><div> object {</div><div> method new(p) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> object {</div><div> def x = 56</div><div> method doit(q) {</div><div> (p + x) ^ q</div><div> }</div><div> }</div><div> }</div><div> } </div><div><br></div><div>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!</div><div><br></div><div><div> object {</div><div> method new(p) {</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span> object {</div><div> def x = 56</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>method p {1}</div><div> method doit(q) {</div><div> (p + x) ^ q</div><div> }</div><div> }</div><div> }</div><div> } </div></div><div><br></div><div>I'm very interested in talking about this more and finding out why the changes that you proposed would help.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span> </div><div><span class="Apple-tab-span" style="white-space:pre"> </span></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Grace-core mailing list</span><br><span><a href="mailto:Grace-core@cecs.pdx.edu">Grace-core@cecs.pdx.edu</a></span><br><span><a href="https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core">https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core</a></span><br></div></blockquote></div></body></html>