Example use case (not resource management; convenient via iterable weak set) #17
Comments
|
This is a great use. Thanks. Can you post a pointer to the code so that we can try enhancing it with weak ref code? I will be interested in trying the proposed weakref approach and trying it with various weak collection options. Also, is there anything in the standard or other source of desire/requirement for making a similar cleanup step if the node is just dropped on the floor (e.g., some incidental additional value in triggering the cleanup). |
|
+1 to "iterable weak set", as another use case I have heard is implementing the "become" operator in languages like Smalltalk. Is it possible to change the title of an issue? If so, I suggest adding "iterable weak set" to the title here. |
|
I got a rather simple other usecase, I've objects representing points in a 2d plane, I like to freeze them and I would like to intern them, so a simple a === b would test them for equality. For this I'd put all the points generated in a weak table with some kind of hash value to test if this object already exists before creating a new one. Similar for objects representing lines or other geometric objects. |
|
@domenic I simply meant using "iterable weak set" in a conceptual sense to summarize the use case described here, not any particular API commitment. |
|
Ah OK, sure, I'll do that if you think that there's a tie between a generalization of this use case and the API shape. |
domenic
changed the title
Note that in the absence of weak references, there is no way to remove a registered NodeIterator once it has been created for a document. If you create a large number of NodeIterators on your document, node removal operations will begin to slow down. See tc39/proposal-weakrefs#17 for more details.
|
@mathiasbynens wrote up something related to this use case in the explainer. Is there anything else to add, or is it OK to close this issue? |
|
Closing due to #17 (comment) |
I have a definite use case for weak references in one of my projects, jsdom. It runs primarily in Node, but also in the browser. Of note, this case isn't related to resource management.
jsdom implements, among other things, the DOM Standard. In particular, there is one line that concerns us here: when removing a node:
To correctly implement this step, you need a reference to every NodeIterator object that's ever been created, so you can update it correctly (by running the pre-removing steps).
This really requires weak references, as otherwise you end up holding a strong reference to every NodeIterator ever created, never releasing their memory, or the memory of the other objects that the NodeIterator references (e.g. the two DOM nodes it points to, root and reference node).
Of note:
Finally, people may be amused by how we currently work around this. We have a user-configurable number, "max working NodeIterators", which we default to 10. We hold strong references to the last 10 created NodeIterators. If an 11th NodeIterator is created, we remove it from the list, then set an internal bit on it that says "sorry, this one's broken", and any methods you try to call on that NodeIterator will throw an exception, helpfully telling you to up the max working NodeIterators configuration.
We then loop over those 10 strongly-held NodeIterators whenever a node is removed from the document, and update them appropriately per the spec.
The text was updated successfully, but these errors were encountered: