<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><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;"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div></div><div><br></div>There is a simple example in the paper, IIRC. It's certainly in the preface to the attached talk — the first 10 slides or so. It has to do with sharing code amongst graphical objects. This includes re-using wrapper code — the example uses a synchronization wrapper, but it could be anything. We who are writing in Grace are already writing stuff more complex than this.<div><br></div><div>The collections classes in Grace contain the same method multiple times because inheritance is inadequate for sharing.<div><div><br><blockquote type="cite"> - which parts of the traits mechanism do we need to solve just those problems?<br></blockquote><div><br></div>Every part that is there, we put there because it was necessary. I would be delighted to take some part out, if it's not necessary.</div><div><br><blockquote type="cite"> - how to incorporate those parts into the existing Grace design?<br></blockquote><div><br></div>Ah, there's the question. I think that we have made some choices that mean that there is no way forward. We have to reconsider them.<br><div><br></div><blockquote type="cite">for me, I think it is worthwhile combining multiple parts of objects together<br>to promote planned reuse (particularly of dialects) which seems to be key to traits.<br></blockquote><div><br></div>All re-use is planned, in the sense that real code (almost) always has to be refactored before it can be reused. What's not planned is the fact that a client may want to (re)use two pieces of code that were designed for separate reuse. This is the rational for Eiffel's deep rename operation. For simplicity, Traits didn't support that. Traits does have an alias mechanism, so that the client can compose two pieces of code that don't know about each other. Michael's suggestion of naming the components (with an <b>as</b> clause) </div><div>is essentially equivalent, I think, and may be a better way to accomplish the same goal.</div><div><br><blockquote type="cite">I’m less convinced on the additional features of traits (for ad-hoc reuse), many <br>trait systems (Scala etc) don’t have that. <br></blockquote><div><br></div>What features are you thinking of?</div><div><br><blockquote type="cite">Then there is the question of how to fit it in to Grace.<br></blockquote><br></div></div></div><div>That is indeed the question. One possible approach is to move the `module.methods` convention into the language. So if one object <b>uses</b> (or<b> includes</b>?) another, it gets all of that object's methods, but none of its state, just like inheriting from `module.methods`</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Andrew</div></body></html>