<div dir="ltr"><div class="gmail_extra"><div>1. Lively supports traits as well. Traits can be applied to classes, objects,</div><div>or traits themselves.</div><div><br></div><div>To try it out, open a rectangle and run</div>
<div><br></div><div>Trait('OnClickTrait', {</div><div>    onMouseDown: function() {</div><div>        show('Someone clicked me!');</div><div>    }</div><div>}).applyTo($morph('Rectangle'), {override: ['onMouseDown']});</div>
<div><br></div><div>(Traits in Lively don't replace methods in the inheritance chain. Since</div><div>#onMouseDown is already implemented in the Morph base class we need the</div><div>"override").</div><div>
<br></div><div><br></div><div>2. The problem is not in finding a language construct to share behavior or do</div><div>mixin-style sideway compositions, the problem is about behavior sharing in a</div><div>distributed setting.</div>
<div><br></div><div>Or to put it differently: How to package up objects and behavior they depend on</div><div>in a non-centralized way that is suitable to use in a high-latency network as</div><div>the Internet and how to manage dependencies between objects and behaviors.</div>
<div><br></div><div>That's pretty abstract, I'll make it more concrete: The example above could be</div><div>"published" by taking the Rectangle and publishing it in the PartsBin. It will</div><div>remember that a OnClickTrait was applied to it. However, it will not serialize</div>
<div>the Trait itself. If the Trait was defined in a module, this module will become</div><div>a load dependency of the Rectangle. So the next time when you load the</div><div>Rectangle the module the Trait is in will be "required".</div>
<div><br></div><div>This is somewhat a solution of the problem you have described but it also adds</div><div>new problems: We now have two kinds of objects/behaviors: Concrete objects in</div><div>the PartsBin and "code" in modules. This clearly is bad:</div>
<div><br></div><div>- There exist only a thin dependency from the object to the module. When</div><div>  changing the module you might not be aware that yu break the object behavior as</div><div>  the module is only tracked by its name not its version.</div>
<div><br></div><div>- There are now two mechanisms to define behavior/state. When should you use</div><div>  which?</div><div><br></div><div>This problem is currently one of the biggest challenges that we hope to solve:</div>
<div>We ideally want a system that consists solely out of objects (objects don't</div><div>need to be concrete, graphical things). Dependencies between those objects</div><div>should be stated flexibly enough so that fine-granular compositions are</div>
<div>possible. If we would have such a system the Trait above would just be another</div><div>PartsBin thing. When it is changed it would either push its changes to the</div><div>Reactangle (if it would still fit the rectangle's requirements) or the</div>
<div>rectangle could be made to pull changes of its dependencies when needed (like a</div><div>"software update").</div><div><br></div><div>So far we have not yet made a lot of progress in this direction but hope to</div>
<div>propose solutions in the future.</div><div><br></div></div></div>