WeakMap API questions?

Mark S. Miller erights at google.com
Sat Aug 14 14:01:08 PDT 2010


On Fri, Aug 13, 2010 at 11:22 PM, Erik Arvidsson
<erik.arvidsson at gmail.com>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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100814/5d06eced/attachment.html>


More information about the es-discuss mailing list