Proposal: Storage for getters and setters

Dean Landolt dean at deanlandolt.com
Fri Sep 30 09:52:35 PDT 2011


On Fri, Sep 30, 2011 at 12:26 PM, Xavier MONTILLET
<xavierm02.net at gmail.com>wrote:

> > Maybe it could use more example use cases. What you're proposing above
> could also be done by keeping the private value in a closure, but if you >
> need to hang it off the object this gives you a way to do that safely.
> Well yes a closure works if you want a value for an object... but as
> soon as you start having several instances, you need to either not use
> the prototype or do some some arrays and store values in them... and
> it kind of sucks...
>

Sure. That's when it helps to be able to hang any old key off the proto in a
way that's guaranteed not to collide. This is what private names give you.
You only need to generate one name object per class, and you can keep this
name object anywhere you'd like, so long as your getter and setter have
access. They interact with `this` by way of the name object, and your
private state is stored on the instance, completely silently (unless some
kind of "visibility flag" came to pass -- then you could choose to expose it
to all but still gain the benefits of name collision avoidance).


> I still don't understand how the thing in the link you psoted works...
> var s = {};
> undefined
> var o = {};
> undefined
> var o2 = {};
> undefined
> s[ o ] = 1;
> 1
> s[ o2 ];
> 1
>

It certainly won't work in an es-current shell. What we've got here is a
coercion fail -- you're using the string key '[object Object]' in `s`. You'd
need to use an actual private name object -- and AFAIK no such
implementation exists.

Does anyone know of one in the works? I suspect it's blocked by a
harmony-modules implementation. And this is a real shame -- like proxies and
weak maps this shouldn't need to wait on modules -- otherwise it's just new
semantics, not syntax. Anyone have ideas on how to get around this? Would it
be so bad to piss a little more in the Object.* namespace pool? It's already
pretty yellow, and the chances of an Object.PrivateName collision are
remote.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110930/084b606a/attachment-0001.html>


More information about the es-discuss mailing list