<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Last weekend, I told James that I was willing try out the idea of used traits not silently overriding an inherited super. I said that the worst that could happened was that one might need to add an occasional “exclude"<div><br></div><div>I just implemented this, and tried it on a version of the collections module. </div><div><br></div><div>The first time I got it working, it reported a conflict on == suitable for any enumerable. A trait (enumerable) provides a definition of ==. But, of course, the superobject (implicitly graceObject) already defines ==. We want the real definition from the trait.</div><div><br></div><div>It’s not simple to put an exclude clause for == on the inherit graceObject, because there is no explicit `inherits graceObject`. </div><div>And if there were, it would be illegal, since graceObject is not fresh.</div><div><br></div><div>In my view, putting in all of these inherit graceObject exclude == exclude asString does not improve anything. <i>Not</i> inheriting from graceObject would only make it worse, because we do want != and asDebugString and :: from graceObject.</div><div><br></div><div>Writing all of these <span style="font-family: Menlo; font-size: 11px;">inherits graceObject exclude == exclude asString </span>clauses also makes me question the idea of multiple exclude keywords, rather than a comma-separated list.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div><div><br></div><div><br></div><div><br></div><div> </div></body></html>