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 <[email protected]> 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 <[email protected]> wrote: >>> On Wed, Nov 26, 2014 at 11:09 AM, Allen Wirfs-Brock >>> <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
