Fwd: Proposal: Storage for getters and setters

[Xavier MONTILLET]

---------- Forwarded message ----------
From: Xavier MONTILLET <xavierm02.net at gmail.com>
Date: Fri, Sep 30, 2011 at 7:20 PM
Subject: Re: Proposal: Storage for getters and setters
To: Dean Landolt <dean at deanlandolt.com>


Alright... So it'll store it with the object as key...
It's really a good idea since you could create a polyfill that just
generates an object with a toString returning some random string and
therefore making collision nearly impossible.
I just tryed implementing it with proxies but when the traps are
called, the object has already turned into a string :/

On Fri, Sep 30, 2011 at 6:52 PM, Dean Landolt <dean at deanlandolt.com> wrote:
>
>
> 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.