Some questions about Private Name Objects

Dean Landolt dean at deanlandolt.com
Thu Sep 13 14:46:06 PDT 2012


On Thu, Sep 13, 2012 at 2:59 PM, Rick Waldron <waldron.rick at gmail.com>wrote:

>
>
> On Thu, Sep 13, 2012 at 1:46 PM, Dean Landolt <dean at deanlandolt.com>wrote:
>
>>
>>
>> On Thu, Sep 13, 2012 at 12:09 PM, Erik Arvidsson <
>> erik.arvidsson at gmail.com> wrote:
>>
>>> On Thu, Sep 13, 2012 at 8:37 AM, Kevin Smith <khs4473 at gmail.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120913/31711f50/attachment.html>


More information about the es-discuss mailing list