Removal of WeakMap/WeakSet clear

[Mark S. Miller]

On Wed, Nov 26, 2014 at 2:49 PM, Katelyn Gadd <kg at luminance.org> wrote:
> The detailed explanations are helpful for understanding this, at least
> when it comes to WeakMap. Thanks. I was not aware that clear() was a
> tenative addition - MDN
> (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap)
> lists it as available in all the major browsers. Understanding it as
> 'should this new thing be added' makes the decision less controversial
> for me even if I personally want the primitive to be there.
>
> However: Does this mean that if I implement clear myself by creating
> new WeakMaps, i'm inadvertently doing horrible things to the GC?

Well, I'll try to explain how expensive I expect it to be, in
qualitative terms, and leave it to you to judge whether it is
horrible. As I mentioned, the original motivating use case for
WeakMaps -- membranes -- throws WeakMaps away in precisely this manner
when the membrane is revoked. So for that use case at least, I do not
consider it too horrible. Nor do I know of any better alternative.


> I get
> the impression that this would mean every time I throw the old map
> away, the data in the keys' hidden maps persists for some unknown
> amount of time,

Yes.

> and I'm adding to that hidden map.

Yes.

> If I destroy and
> repopulate these maps on a regular basis that seems like it could get
> out of hand quickly.

If you're doing this at greater frequency than the expected lifetime
of the keys, then I need to ask: Why are you using a WeakMap instead
of a Map? (An example would be great)


> If this usage pattern is fundamentally bad for JS
> VMs, it seems like the sort of guidance that probably needs to be
> clearly messaged to users - 'clear() isn't available because you
> really, really shouldn't do that' vs 'clear() isn't available because
> you can write it yourself'. Just my 2c there - very interesting to
> know about the reasoning behind this.

Sure. But this kind of advice is outside the normative spec. Perhaps
it is more appropriate for the various outlets authored by many of the
authors here on es-discuss? (Both those on and not on TC39)


-- 
    Cheers,
    --MarkM