Le 22/01/2013 15:19, Jason Orendorff a écrit :
On Tue, Jan 22, 2013 at 5:56 AM, David Bruant <bruan...@gmail.com
<mailto:bruan...@gmail.com>> wrote:
Le 22/01/2013 11:47, Jason Orendorff a écrit :
On Mon, Jan 21, 2013 at 6:04 AM, David Bruant <bruan...@gmail.com
<mailto:bruan...@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 [1] (that was his #1). I answered [2]: "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 [3].
What problem exactly?
I was wrong in saying "*the* problem". A problem may arise, this problem
being that there is a risk that you were relying on some entries and
that they may disappear at any time making your code harder to reason about.
[re-ordering]
Also, I don't understand how [3] is a use case for sharing weakmaps
around. To me it looks like a use case for clearing a WeakMap.
I was imagining that some of the different phases could be performed by
third-party code. But since the use case is about a cache, there is no
reason one would rely on the existence of some entries. Maybe a more
subtle use case needs to be found.
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.
If WeakMap.prototype.clear is part of the built-in API, an attacker
(including buggy code) can do WeakMap.prototype.clear.call(yourWeakMap),
so "exposing a read-only view" means wrapping pretty much the way Mark
Miller implemented clear
class WeakMapWithoutClear {
private let wrapped;
constructor() {
wrapped = new WeakMap();
}
get(key) => wrapped.get(key),
set(key, val) => wrapped.set(key, value),
has(key) => wrapped.has(key),
delete(key) => wrapped.delete(key)
}
What this and my previous show is an semantics equivalence between
clearable and clear-less weakmaps. Which should be chosen as default?
* clear-less weakmaps have better integrity properties.
* clearable weakmaps may have better performance characteristics (I'm
still not entirely convinced)
Are use cases for .clear that common that they justify being put in the
native API? Or is it acceptable to ask those who want it to wrap in classes?
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
