jason.orendorff at gmail.com
Tue Jan 22 06:19:33 PST 2013
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 22/01/2013 11:47, Jason Orendorff a écrit :
> On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruant.d at gmail.com> wrote:
>> [...] WeakMap.prototype.clear questions the property that was true before
>> its adoption ("you can only modify a weakmap entry if you have the key")
> David, would you please elaborate your argument for this invariant? This
> the first I've seen it stated.
> An invariant can be a powerful thing. Still, I guess my default position
> is that (1) the object-capabilities perspective is only one view among
> many; (2) even looking at things with an eye for o-c integrity and
> security, clearing a data structure seems like a reasonable thing to allow,
> treating a reference to the data structure itself as a sufficient
> capability. It's (2) that I would especially like you to address.
> I think Rick already suggested your (2), though phrased a bit differently
>  (that was his #1). I answered : "I thought more about how I use
> weakmaps and [well-encapsulate my weakmaps so that I'm the only holder] is
> a thing I do naturally indeed."
> The problem may arise when you start sharing weakmaps around and some use
> cases require you to .
What problem exactly?
Sharing mutable data structures across abstraction (or trust) boundaries is
already pretty well understood to be an integrity (or security) risk. It's
easy to fix: you expose a read-only view instead.
Also, I don't understand how  is a use case for sharing weakmaps around.
To me it looks like a use case for clearing a WeakMap.
Thanks for the response.
>  https://mail.mozilla.org/pipermail/es-discuss/2013-January/028380.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss