<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:'times new roman', 'new york', times, serif;font-size:12pt"><div>Hi Tom</div><div><br></div><div>The 'pattern' I'm describing has some similarities to <a href="http://en.wikipedia.org/wiki/Multiple_dispatch">multi-methods</a>.&nbsp;</div><div>An example is a drawing program. Depending on 'context' which&nbsp;</div><div>includes the user agent, the type of drawing primitive and the type&nbsp;</div><div>of drawing filter or effects you need to dynamically build an object which&nbsp;</div><div>chooses vml, flash, svg or canvas. The drawing object is told to draw&nbsp;</div><div>a circle with a linear gradient. As the designer you do not want to&nbsp;</div><div>download implementations of vml, flash, svg and canvas. You also do&nbsp;</div><div>not want to build a container object which has gratuitous if statements</div><div>to do delegation or contains
 knowledge of all implementations. This would not&nbsp;</div><div>scale given you would like the design to be extensible. For example&nbsp;</div><div>next week you may want to add silverlight.&nbsp;You also would like to only download&nbsp;</div><div>resources based things like user agent and version&nbsp;(vml for ie, svn and/or canvas for&nbsp;</div><div>webkit, firefox,&nbsp;opera depending on&nbsp;the type of primitive and effect). Patterns like &nbsp;</div><div><a href="http://en.wikipedia.org/wiki/Template_method_pattern">template-methods</a>&nbsp;do not apply because each implementation may&nbsp;</div><div>take different parameters in its methods and given a user agent/version you&nbsp;</div><div>may want to do a drawCircle using a canvas on firefox but use svg&nbsp;</div><div>on iphone and use flash on webkit. It doesn't sound like traits would&nbsp;</div><div>enable this 'pattern' given different methods need to be mixed in
 with&nbsp;</div><div>appropriate context from the implementation and all methods are final.&nbsp;</div><div>Also it doesn't look like you could draw a circle and pass things like border,</div><div>background&nbsp;in a closure rather than explicitly through parameters, although</div><div>you allude to a way via the property descriptor. Passing attributes like&nbsp;</div><div>background, border in the property descriptor would seem to be an abuse&nbsp;</div><div>of the meta-data framework by passing data not meta-data.</div><div><br></div><div>thx</div><div>kam</div><div><br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> Tom Van Cutsem &lt;tomvc@google.com&gt;<br><b><span style="font-weight: bold;">To:</span></b> Kam Kasravi
 &lt;kamkasravi@yahoo.com&gt;<br><b><span style="font-weight: bold;">Cc:</span></b> es-discuss &lt;es-discuss@mozilla.org&gt;<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, February 16, 2010 7:18:48 PM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: Traits library<br></font><br>
Hi Kam,<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><div style="font-size:12pt;">
<div>If I understand the implementation of traits, it provides a ES5 compatible way of composing 'final' properties to an existing object's prototype.</div><div>Options provide the meta-data required to define the property descriptor such as required, etc. Do traits provide an ability to bind&nbsp;</div>
<div>a 'context' to the property in the form of a closure so that the property may be provided with additional information?</div><div>Effectively a way to curry or export additional information required by the trait when it is called in the context of the object it was added to.</div>
</div></div></blockquote><div><br></div><div>I'm not entirely sure I understand the question. Do you have a particular use case in mind or can you give an example to clarify things?</div><div>As far as I can understand, if what you want is additional meta-data stored in property descriptors, this can be done by adding additional attributes to the descriptors.&nbsp;In effect, that's what the library already does for 'required' and 'conflicting' properties.</div>
<div><br></div><div>Cheers,</div><div>Tom</div><div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div style="font-size:12pt;">
<div><br></div><div>thx</div><div>kam</div><div><br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt;"><br><div style="font-family:times new roman, new york, times, serif;font-size:12pt;">
<font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Tom Van Cutsem &lt;<a rel="nofollow" ymailto="mailto:tomvc@google.com" target="_blank" href="mailto:tomvc@google.com">tomvc@google.com</a>&gt;<br><b><span style="font-weight:bold;">To:</span></b> es-discuss &lt;<a rel="nofollow" ymailto="mailto:es-discuss@mozilla.org" target="_blank" href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a>&gt;<br>
<b><span style="font-weight:bold;">Sent:</span></b> Tue, February 16, 2010 2:55:50 PM<br><b><span style="font-weight:bold;">Subject:</span></b> Traits library<br></font><div><div></div><div class="h5"><br>
Hi,<div><br></div><div><span><span>Mark Miller and I have been working on a small traits library for Javascript. It is documented here: &lt;<a target="_blank" href="http://code.google.com/p/es-lab/wiki/Traits">http://code.google.com/p/es-lab/wiki/Traits</a>&gt;</span></span></div>




<div><br></div><div>Traits are reusable building blocks for classes, very similar to mixins, but with less gotchas. For example, traits support explicit conflict resolution upon name clashes and the order in which traits are composed is not significant.</div>



<div><br></div><div>In a nutshell:</div><div>- The library is designed for ES5, but backwards-compatible with existing ES3 implementations.</div><div>- Our library represents traits as ES5 property maps (objects mapping property names to property descriptors). The library exports:</div>


<div>&nbsp;-&nbsp;a convenient trait "constructor" to generate property maps from object literals.</div>

<div>&nbsp;- a number of&nbsp;"trait combinators" to compose property maps.</div><div>&nbsp;- a function that can "instantiate" such property maps into objects (analogous to the ES5 Object.create function, but with awareness about trait-specific property semantics).</div>


<div><br></div><div>The interesting thing about our choice of transparently representing traits as ES5 property maps is that our library can be used as&nbsp;a general-purpose library for manipulating property descriptors in addition to its use as a library to compose and instantiate traits.</div>


<div><br></div>

<div>A small expository example that uses the library:</div><div><span><span>&lt;<a target="_blank" href="http://code.google.com/p/es-lab/source/browse/trunk/src/traits/examples.js">http://code.google.com/p/es-lab/source/browse/trunk/src/traits/examples.js</a>&gt;</span></span></div>




<div><br></div><div>Mark and I were both surprised at how well Javascript&nbsp;accommodates&nbsp;a trait library with very little boilerplate. However, there is one catch to implementing traits as a library. Traits, like classes, are normally simply declared in the program text, but need not necessarily have a runtime representation.&nbsp;Trait composition is normally performed entirely at compile-time (in trait lingo this is called "flattening" the traits). At runtime, no trace of trait composition is left.</div>




<div><br></div><div>Because we use a library approach, traits are not declarative entities and must have a runtime representation.&nbsp;Thus, there is a runtime overhead associated with trait creation and composition. Moreover, because the implementation is oblivious to traits, multiple objects instantiated from the same trait "declaration" don't share structure. However, we did design the library such that, if traits are specified using object literals and property renaming depends only on string literals (which is the common case), a partial evaluator could in principle perform all trait composition statically, and replace calls to Trait.create with a specialized implementation that does support structural sharing between instances&nbsp;(just like an implementation that notices multiple calls to Object.create with the same property descriptor map can in principle arrange for the created objects to share structure).</div>




<div><br></div><div>Any feedback on our design is welcomed.&nbsp;In particular, it'd be interesting to hear how hard/easy it would be for an implementation to recognize the operations performed by our library in order to perform them statically.</div>




<div><br></div><div>Cheers,</div><div>Tom</div>
</div></div></div></div><div></div>


</div></div></blockquote></div><br></div>
</div></div><div style="position:fixed"></div>


</div></body></html>