On Thu, Sep 13, 2012 at 2:59 PM, Rick Waldron <[email protected]>wrote:
> > > On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt <[email protected]>wrote: > >> >> >> On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson < >> [email protected]> wrote: >> >>> On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith <[email protected]> wrote: >>> > 1) Is method name-collision a practical problem, or just a theoretical >>> > problem? If it's just a theoretical problem, then we don't need unique >>> > names, and in teaching the language we can simply guide users away from >>> > trying to create "private methods". In fact, without supporting >>> syntax it's >>> > unlikely that users would even bother trying to create them in the >>> first >>> > place. >>> >>> Yes. This is a real problem. >>> >>> It is a common problem that we see a lot with "private" members using >>> naming conventions. >>> >>> class Base { >>> constructor() { >>> this._element = ...; >>> } >>> } >>> >>> class Derived extends Base { >>> constructor() { >>> this._element = ...; // OOPS! >>> } >>> } >>> >> >> >> 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: >> >> var rec = new Record({ save: 'whoops' }); >> rec.save() // TypeError: Property 'save' is not a function >> >> 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. >> > > This could also be designed to use a WeakMap as the "store" for the data :) > > https://gist.github.com/3716743 > 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. 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
