On Fri, Aug 13, 2010 at 11:22 PM, Erik Arvidsson <[email protected]>wrote:
> I have a few questions regarding the WeakMap API. > > 1. Why isn't there a way to check for presence of a key (using > has/contains)? > > Given that undefined is a valid value it is not sufficient to just > return undefined for get > Simplicity without loss of generality. The example at < http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#explicit_soft_own_fields> shows how to build a WeakMap-like API as a thin layer on WeakMaps that implements the four method API you have in mind. Of course, layering this the other way would work too. Since both are plausible, it seems a better layering to have the primitive abstraction be the simpler one. Semantically, the way to understand the simpler API is that each WeakMap starts out as a mapping from all possible object identities to undefined. Thus, they only need to record those cases that map to something other than undefined. > > > 2. Why isn't there a way to remove a key-value-pair? > > Setting the value to undefined is not the same. > Depends on the meaning of the abstraction. For WeakMaps, setting to value to map to undefined is to restore the mapping to its initial state, which requires no storage. For < http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#explicit_soft_own_fields>, setting the value to undefined is indeed not the same as deleting it, so that abstraction provides an explicit delete operation. > > > 3. Why isn't there a way to iterate over the keys? > > I can see that this might be a security issue but iteration is useful > and security sensitive code can prevent iteration in several ways. > Little code should be "security sensitive" in the sense of "my security relies on the correctness or good intentions of this code". Virtually all code should be "security sensitive" in the sense of "my security should not rely on the correctness or good intentions of this code". The classic covert channel problem is to prevent untrusted code under our control from signaling to untrusted code not under our control. I agree with the general (but not universal) consensus that this is too hard to be practical. However, the inverse problem is practical: To prevent untrusted code under our control from being able to read from covert channels on which others are signaling. Exposing the non-determinism of garbage collection opens up the ability read from a huge high bandwidth covert channel. Although JavaScript today has various forms of non-determinism, I do not know of any other hard to plug covert channels in JavaScript which are this bad. > > 4. Why does set throw if the key is not an object but get doesn't? > Set throws because it is preventing these from becoming keys in the table. Set thus is an LSP (Liskov Substitutability Principle) subtype of Map.set only in the weaker sense of obeying the super contract in those cases where it does not throw. Since non-object keys are absent from the table, get can fulfil the full supertype contract by correctly and successfully reporting their absence. > > Same would go for delete and has if those are added. > In < http://wiki.ecmascript.org/doku.php?id=harmony:weak_maps#explicit_soft_own_fields>, both set and delete throw. Neither get nor has throw. I think this is right for the same LSP reasons. > > -- > erik > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
