On Thu, Sep 13, 2012 at 5:46 PM, Dean Landolt <[email protected]> wrote:
> > > 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. > 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. https://github.com/rwldrn/fact(even that's at the mercy of property name collision (eg. on, off, emit... etc) and desires some form of "purified prototype chain".) > > 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
