On Thu, Dec 4, 2014 at 6:58 AM, David Bruant <[email protected]> wrote: > Sometimes you call functions you don't have written and pass arguments to > them. WeakMaps are new, but APIs will have functions with WeakMaps as > arguments. I don't see what's crazy. It'd be nice if I don't have to review > all NPM packages I use to make sure they dont use .clear when I pass a > weakmap.
...Under what circumstance would you see yourself doing that? Do you review all the code in NPM packages you use now? Maybe you look at the source when there's a bug. So is calling .clear() on an argument that's not supposed to be modified a particularly likely bug somehow? > If you don't want to pass the WeakMap directly, you have to create a new > object "just in case" (cloning or wrapping) which carries its own obvious > efficiency. Security then comes at the cost of performance while both could > have been achieved if the same safe-by-default weakmap can be shared. This is some rhetorical sleight of hand. Logic can't support any meaning of "safe" here except "safe from clear (and only clear)". But that's not the only or the most interesting mischief a function with a reference to a WeakMap can get up to. set() and delete() are much more interesting. > We know ambiant authority is a bad thing, examples are endless in JS. This much I agree with, and I think it's your best framing of the question so far, but... > WeakMap.prototype.clear is ambiant authority. Here you're just asserting your conclusion. I don't see it as ambient authority. It can only operate on the object you pass to it. > I would return the question: can you demonstrate there are no such scenario? It's hard to prove a negative, but certainly the same technique which JS programmers already use to avoid having their objects mutated in unwanted ways also works great with WeakMaps: don't pass around direct references to them. And I can certainly demonstrate that removing WeakMap#clear does *not* make it "safe by default" to pass a WeakMap you care about to bad code. I think a .freeze() or .frozenCopy() method would be a productive way of getting the sort of guarantee you're interested in. Immutable data structures might be even better. -j _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
