Removal of WeakMap/WeakSet clear

[Katelyn Gadd]

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? 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, and I'm adding to that hidden map. If I destroy and
repopulate these maps on a regular basis that seems like it could get
out of hand quickly. 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.

On 26 November 2014 at 13:28, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
> On Nov 26, 2014, at 11:25 AM, Tab Atkins Jr. wrote:
>
>> On Wed, Nov 26, 2014 at 11:23 AM, Mark S. Miller <erights at google.com> wrote:
>>> On Wed, Nov 26, 2014 at 11:09 AM, Allen Wirfs-Brock
>>> <allen at wirfs-brock.com> wrote:
>>>>
>>>> On Nov 26, 2014, at 10:22 AM, Claude Pache wrote:
>>>>
>>>>
>>>> The root of the issue, is that WeakMaps are thought as a tool for two
>>>> unrelated use cases. Quoting [1]:
>>>>
>>>> (...) WeakMaps were motivate[d] by two distinct use cases.  Soft fields and
>>>> object-keyed caches.
>>>>
>>>>
>>>> Now, in short, for the "soft fields" use case, a `.clear()` method is
>>>> unwanted, but for the "object-keyed caches" use case, a `.clear()` method is
>>>> welcome.
>>>>
>>>> —Claude
>>>>
>>>> [1]: https://esdiscuss.org/topic/weakmap-clear-and-inverted-implementations
>>>>
>>>>
>>>> Let's ignore security for  the moment.
>>>>
>>>> If  WeakMaps/WeakSets are not inspectable (via iteration) and do not have a
>>>> clear operation, then the inverted implementation technique can be use used.
>>>> This technique eliminates significant GS complexity.
>>>>
>>>> The ability to iterate over the elements of a WeakMap/Set would make
>>>> implementation specific (and probably non-deterministic) GC timing
>>>> observable to ES programs.  Non-deterministic and observable implementation
>>>> specific behavior is bad for interoperability.
>>>
>>> Hi Allen, as much as I'd like to agree with this, I don't see the
>>> observability-of-GC issue. Could you explain more? Thanks.
>>
>> Allen appears to be mixing in an iterability argument.  This isn't
>> germane to the .clear() discussion, unless you think of .clear() as
>> being implemented by iterating and removing keys.
>
> Right, it's the lack of iterability and clear that makes the  inverted implementation feasible.  We justify lack of iterability because it exposes GC.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss