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. > That reason alone is enough > for TC39 to choose to not make WeakMaps/Sets non-iterable as > interoperability is one of our highest priorities. > > That said, there are use cases for iterable weak collections if you are > willing to tolerate the non-determinism and observability of the GC. > Implementations supporting situation where those use cases are important > might choose to provide a non-standard IterableWeakMap/Set implementation > and there would be no particular reason for not including a 'clear' method. > If there of evidence of enough utility for such collections TC39 might even > decide to standardize them. In which case we would probably but them into a > standard module that needs to be explicitly imported. Use of the module > would be a flag that the program may have non-deterministic behavior. > > Allen > > > > > Le 26 nov. 2014 à 18:33, Katelyn Gadd <[email protected]> a écrit : > > > Is there a detailed rationale for this somewhere? Making typical > > applications pay the cost here for a specific security scenario seems > > really bizarre to me. Clearing standard library data structures is an > > incredibly common operation. If you want to ensure that someone can't > > clear the map/set, shouldn't you be handing them an encapsulated > > version of the data structure? This seems like a corner case that > > shouldn't justify removing an important primitive. > > > If you have a clear method, the security problem seems solved by > > wrapping it in an object or using a proxy to deny the ability to clear > > (you hide the actual map/set, so it can't be cleared - you expose only > > the operations you want to expose). > > > If you don't have a clear method, anyone wanting to clear the data > > structure has to throw it away and allocate a new one. This has > > significant disadvantages: > > The new structure starts empty at a default size, so repopulating it > > will have to grow the buffer multiple times - this is undesirable for > > cases where you are reusing a single data structure to store state for > > a long-running application. > > The allocation adds to GC and memory pressure for a long-running > > application that needs to clear data structures frequently. Were it a > > lightweight data type this would matter less, but a typical map > > instance with data in it can occupy a considerable amount of space in > > the heap. > > Being able to clear the structure now requires that all consumers have > > support for replacing their reference(s) to the old map with the new > > one. This makes it harder to maintain encapsulation because you may > > have saved a reference to the map in a private property or within a > > closure. Now you need to add accessibility points to everything that > > might retain the map so that you can update the reference. Or, you > > have to encapsulate maps and sets just to recreate the clear operation > > that should have been there to begin with. > > > In either case, encapsulation or shielding the container behind a > > proxy is necessary. I insist that the common case is the one that > > shouldn't have to encapsulate, because optimizing for that case will > > benefit the vast majority of web applications that use it and the > > penalty to security-sensitive cases is small. > > > -kg > > _______________________________________________ > > 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 > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
