Some questions about Private Name Objects

[Rick Waldron]

On Thu, Sep 13, 2012 at 5:46 PM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
> 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.
>

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120914/c715b8f7/attachment.html>