<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">In an attempt to ground the discussion, let me try to explain what I think the problem is that Michael’s email is starting to address.<div><br></div><div>Here is a (slightly edited) snippet from the collections prelude — I find real examples more instructive than "a, b, c" examples.</div><div><br></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><b>class</b> collection.trait<T> {</div><div> // requires withAll(elts:Collection<T>) -> Collection<T></div><div> <b>method</b> with(*a:T) -> Unknown { self.withAll(a) }</div><div> <b>method</b> empty -> Unknown { self.with() }</div><div>}</div><div><br></div><div><b>factory</b> <b>method</b> list<T> {</div><div> <b>inherits</b> collection.trait<T></div><div><br></div><div> <b>method</b> withAll(a:Collection<T>) -> List<T> { … }</div><div><br></div><div>}</div></blockquote><div><br></div><div><br></div><div>This looks fine at first sight. list inherits from collection.trait, which seems to be lexically bound, and thus “definitively static”. The compiler knows what it means, and all is well.</div><div><br></div><div>But wait. Suppose that gUnit inherits from list:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>class testSuite.forMethod(methodName) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>inherits list<Test></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>…</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>method collection { … }</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>…</div><div>}</div><div><br></div></blockquote>Now, what does “collection.trait” mean in the collections prelude (line 8 of the first snippet)? According to the current language rules, ‘collection’ is ambiguous: it is defined both on the lexical chain (as a class) and on the inheritance chain, because a subclass of list defines it. So the compiler must reject the definition of list, and require the programmer to write either <b>outer</b>.collection.trait or <b>self</b>.collection.trait. (The latter, of course, fails the “definitively static” test).</div><div><br></div><div>The problem is that the compiler can hardly reject “<b>inherits</b> collection.trait” under these circumstances, because that would mean rejecting almost all inheritance.</div><div><br></div><div>The solution that I suggested during the teleconference last week was to record, in an "heir’s specification” for list, the fact that the code in list assumes that the name ‘collection’ is <i>not</i> defined in list <i>or in any of its sub-objects</i>. This would enable the inheritance of ‘list’ in ‘testSuite’ to be flagged as illegal (because the definition of a method called ‘collection’ will make the definition of ‘list’ illegal).</div><div><br></div><div>Other solutions involve chaining the name resolution rules. For example, if all self requests had to use an explicit self, then lexical bindings and dynamic bindings would be syntactically distinguishable — this is the AmbientTalk solution, I believe. Another possibility would be to say that <i>all</i> inherits expressions are lexically bound, and that the dynamic chain is never consulted when resolving them. (I think that this would change the language in significant ways, because it would effectively introduce private methods and variables. It also seems a bit strange to have one rule for inherits expressions and another rule for other expressions.)</div><div><br></div><div>I’m guessing that Michael’s email is an attempt to look at alternative name resolution rules, but I don’t understand how his rules would deal which this example.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><span class="Apple-tab-span" style="white-space:pre"> </span></div></blockquote></div></body></html>