<br><br><div class="gmail_quote">On Thu, Sep 13, 2012 at 5:46 PM, Dean Landolt <span dir="ltr"><<a href="mailto:dean@deanlandolt.com" target="_blank">dean@deanlandolt.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div><div class="h5">On Thu, Sep 13, 2012 at 2:59 PM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br><br><div class="gmail_quote"><div><div>On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt <span dir="ltr"><<a href="mailto:dean@deanlandolt.com" target="_blank">dean@deanlandolt.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><br><br><div class="gmail_quote">On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson <span dir="ltr"><<a href="mailto:erik.arvidsson@gmail.com" target="_blank">erik.arvidsson@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith <<a href="mailto:khs4473@gmail.com" target="_blank">khs4473@gmail.com</a>> wrote:<br>
> 1) Is method name-collision a practical problem, or just a theoretical<br>
> problem?  If it's just a theoretical problem, then we don't need unique<br>
> names, and in teaching the language we can simply guide users away from<br>
> trying to create "private methods".  In fact, without supporting syntax it's<br>
> unlikely that users would even bother trying to create them in the first<br>
> place.<br>
<br>
</div>Yes. This is a real problem.<br>
<br>
It is a common problem that we see a lot with "private" members using<br>
naming conventions.<br>
<br>
class Base {<br>
  constructor() {<br>
    this._element = ...;<br>
  }<br>
}<br>
<br>
class Derived extends Base {<br>
  constructor() {<br>
    this._element = ...;  // OOPS!<br>
  }<br>
}<br></blockquote><div> </div><div><br></div></div></div>Another good example where this is a problem is on prototype chains, a good example of which you parenthetically noted (iterators). With unique names it becomes feasible to hang any properties and methods you want off of prototypes without worrying about collision. For instance, imagine an persistance lib with a Record.prototype.save method:<div>







<br></div><div>    var rec = new Record({ save: 'whoops' });</div><div>    rec.save() // TypeError: Property 'save' is not a function</div><div><br></div><div>And thus we all fall back to the lovely Record.prototype.save.call(rec) pattern. Unique names neatly sidestep this, giving us back our prototype chains.</div>





</blockquote><div><br></div></div></div><div>This could also be designed to use a WeakMap as the "store" for the data :)</div><div><br></div><div><a href="https://gist.github.com/3716743" target="_blank">https://gist.github.com/3716743</a></div>



</div></blockquote><div><br></div><div><br></div></div></div><div>Sure, but now we're back to the whole object.get/set pattern -- to be otherwise rendered irrelevant by the Object.observe proposal (fingers crossed). There's clearly demand for treating objects as records instead of playing interface gymnastics. And when writing generic code we don't always have that luxury. Names (or Symbols, or whatever we're calling them these days) finally allow us to use the prototype chain safely w/ high integrity lookups.</div>

</div></blockquote><div><br></div><div>Of course and I've been a constantly vocal champion of Object.observe. Instead of further abusing the "plain object", I think a better way forward is designing smart "record object" constructors that construct instances that are pre-initialized as observable, eg. <a href="https://github.com/rwldrn/fact">https://github.com/rwldrn/fact</a> (even that's at the mercy of property name collision (eg. on, off, emit... etc) and desires some form of "purified prototype chain".)</div>

<div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">

<div><br></div><div>The real point I'm trying to make is that Name objects give us something akin to clojure's protocols. Imagine an "orm" protocol -- this is just a set of names that must exist on an object (or its proto chain). An object can implement any number of protocols (or interfaces, or whatever) without fear of conflict. You can easily override any implementation so long as you have a handle on the appropriate name object. This is easier, better looking and more correct than anything we can do today. It's not too disimilar from using using instanceof as a brand, but without the pitfalls (it doesn't fall flat crossing sandbox boundaries). This is a safe and flexible inheritance model that works just as a js programmer would expect, all without begging for mutable or multiple prototypes.</div>



<div><br></div></div>
</blockquote></div><br>