I would like to agree that .keys would expose some of the internal workings
of the GC. This is true, but the solution to that could be to remove .keys()
off the individual WeakMap for secure operations, however in some situations
where a WeakMap is sandboxed within a closure or such, having .keys allows
for sharing private variables between objects discretely without exposing
them to the public eye (similair to the friendly idea in c++). Lets take a
look at a use case of weak maps to hold private information:

(function(){
var hiddenMap = new WeakMap()
//constructor function
Foo = function Foo() {
  var private = {friends:[]}
  hiddenMap.set(this,private)
}
Foo.prototype.verifyAgainst = function(otherFoo) {
  var otherFoo_private = hiddenMap.get(otherFoo)
  var thisFoo_private = hiddenMap.get(this)
  
if(otherFoo_private.friends.indexOf(this)!==-1&&thisFoo_private.friends.indexOf(otherFoo)!==-1)
{
    //do something only friends can do
  }
}
Foo.prototype.extend = function(subconstructorFactory) {
  return subconstructorFactory(hiddenMap)
}
})()
...
known to be secure code
...
Foo.prototype.extend = null
...
non-secure code
...

Now say we extend Foo with Bar (inside the secure code area), and Bar wants
to request access to all of the Foos in order to track which Foos are
friends with each other on both ends. How will we be able to get a list of
all the Foos in existence without leaking right now? The only possibilities
I see are to not allow these sort of operations or to leak. On the level of
use, it seems to me like a strict mode case vs a normal mode case unless we
gain a collector callback.

On Thu, Sep 2, 2010 at 2:46 AM, Erik Corry <erik.co...@gmail.com> wrote:

> 2010/8/14 Mark S. Miller <erig...@google.com>:
> > On Sat, Aug 14, 2010 at 1:01 PM, Ash Berlin <ash...@firemirror.com>
> wrote:
> >>
> >> On 14 Aug 2010, at 07:22, Erik Arvidsson 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
> >>
> >> Does the standard trick of:
> >>
> >>  if (key in weakMapInstance) { }
> >>
> >> not work?
> >
> > It does not. A key is not a property name. A weak map is an object with
> two
> > own properties, names "get" and "set", whose values are the methods that
> > constitute the weak map API.
> >
> >>
> >> >
> >> > 2. Why isn't there a way to remove a key-value-pair?
> >> >
> >> > Setting the value to undefined is not the same.
> >>
> >> Again:
> >>
> >>  delete weakMapInstance[key];
> >
> > No. This syntax deletes named properties.
> >
> >>
> >> > 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.
> >>
> >>  Object.keys(weakMapInstance)
> >
> > No. Object.keys enumerates property names.
>
> And this is as it should be.  As it stands the weak map can be used as
> an object with private members.  The object key acts as a capability
> that controls whether or not you have access to the private member.
> If you are allowed to enumerate the keys then privacy goes out of the
> window.
>
> >
> >>
> >> >
> >> > 4. Why does set throw if the key is not an object but get doesn't?
> >> >
> >> > Same would go for delete and has if those are added.
> >>
> >>
> >>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > --
> >     Cheers,
> >     --MarkM
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to