Hi Dmitry,<div><br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">Hi MarkM and Tom, possibly it will be interesting to you:
    <a href="http://gist.github.com/613924" target="_blank">http://gist.github.com/613924</a> -- a delegation based mixins
    implemented using Harmony proxies.<br>
    <br>
    Features:<br>
    <br>
      - working in two modes: traits (naming conflict predicting at
    early stage), or simple linearization (mixins mode, there is no
    warning about naming conflicts);<br>
    <br>
      - &quot;in&quot; operator is working on object (e.g. <i>&quot;foo&quot; in bar</i> is
    <i>true</i> if either <i>bar</i> has own property &quot;foo&quot;, or any of
    mixed objects have the property (including consideration of their
    prototype and mixin chains), or if the property is found in the
    prototype chain of the <i>bar</i>).<br>
    <br>
    Cons: possible overhead on reading / or testing for &quot;in&quot;. Should be
    avoided at lower level implementation.<br>
    <br>
    TODO: syntactic sugar (possibly for CoffeeScript).<br></div></blockquote><div><br></div><div><div>It&#39;s an interesting experiment. On first sight, your inheritance mechanism looks very similar to Ruby&#39;s modules. Although one big difference is that in your experiment, your mixins can also have their own prototype chain (IIRC in Ruby, modules can&#39;t inherit). I think that may be a bit too flexible, leading to even more complex lookups than is the case with multiple inheritance. If you would ignore the prototype of the mixins, you end up with something called &quot;comb inheritance&quot; (at each level, check the object and the mixins horizontally, if not found go up one level on the prototype chain and try again) which is a bit more tractable for programmers to deal with, I think.</div>
<div><br></div><div>Your experiment does show that it&#39;s possible to combine conflict detection + delegation to some extend. However, I wouldn&#39;t call your conflict detection mode &quot;trait mode&quot;. First: the system is not conflict-proof: if some code adds a property to a mixin object or to the target object at a later point in time, potential conflicts will go undetected. Second, even in &quot;trait mode&quot; the ordering of the mixins matters (trait composition is commutative, ordering is not important, at any level of composition). Third, there seems to be no obvious way to resolve/avoid a signaled conflict (traits have aliasing or overriding to deal with this).</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">
    <br>
    P.S.: it&#39;s good to have <i>noopHandler</i> for proxies as a
    built-in function, it&#39;s a useful sugar (possibly even to make it as
    a default handler (if some handler&#39;s properties are not specified),
    though it may be unnecessary overhead).<br></div></blockquote><div><br></div><div>Yes, I agree! We&#39;ve talked about this in the past but haven&#39;t yet settled on a standard API. Perhaps we should.</div><div>I think Proxy.noopHandler(target) may be a bit obscure. Other suggestions:</div>
<div>Proxy.createHandler(target)</div><div>Proxy.forward(target)</div><div>Proxy.handle(target)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div bgcolor="#ffffff" text="#000000">

    <br>
    P.S.[2]: proxies are nice ;)<br></div></blockquote><div><br></div><div>Thanks! Keep on experimenting :-)</div><div></div></div><br></div><div>Cheers,</div><div>Tom</div>