Normative: Refine definition of reachability - #120
Conversation
This attempts to address various issues with how reachability is defined: - If one WeakRef object points to an object, which points to another one, the whole subgraph may be collected, as raised in https://gist.github.com/jimblandy/0014dc11233d2d40df922af850b0489a - An initial provisional definition of collectability is given: > No possible future execution of the program would observably > reference the object, except through a chain of references which > includes a [[Target]] field or [[Target]] internal slot. This is intended to resolve tc39#31 (by concluding that the impact on host specifications is minimal, and spec graph reachability does not imply liveness) and provide a starting point for tc39#105 - The wording around 'field or internal slot' is clarified, resolving tc39#115
| <li> | ||
| No possible future execution of the program would observably | ||
| reference the object, except through a chain of references which | ||
| includes a [[Target]] field or [[Target]] internal slot. |
There was a problem hiding this comment.
this, i think, still needs the same clarification in lines 116-117? (an alternative would be an abstract operation rather than using prose to describe [[Target]] interaction)
There was a problem hiding this comment.
Well, I made sure [[Target]] referred separately to "field" and "internal slot"; isn't it pretty clear what we're talking about given the mention a couple lines earlier? Nothing else uses an internal slot of this name.
There was a problem hiding this comment.
I’m thinking about future uses which might, but might not be intended to be included here. It seems like it wouldn’t hurt to be overly explicit here, even though it’s certainly implied?
There was a problem hiding this comment.
I don't think that's how the ES spec is generally written. If an internal slot name is accidentally reused, then, for example, type checks will accidentally pass. The name "[[Target]]" is solidly owned by this proposal, or it will break.
There was a problem hiding this comment.
Fair point - the updated version seems good to me, thanks!
|
Section 1.5 Modifications to collection type definitions contains similar phrasing that was reworded here.
Should that not be updated as well? |
|
@mhofman Ah right, good catch--would you be up for writing a PR to address that? |
|
I was wondering if that sentence wouldn't become too convoluted if the same change was applied?
Which also make me wonder why WeakMap/WeakSet entries are not mentioned in the listed conditions here for emptying the slot/field? Btw, looking at the WeakMap spec, shouldn't the following also be reworded:
|
3 participants
This attempts to address various issues with how reachability
is defined:
If one WeakRef object points to an object, which points to
another one, the whole subgraph may be collected, as raised in
https://gist.github.com/jimblandy/0014dc11233d2d40df922af850b0489a
An initial provisional definition of collectability is given:
This is intended to resolve Interesting impact on other specifications #31 (by concluding that the impact on
host specifications is minimal, and spec graph reachability does not
imply liveness) and provide a starting point for Decoupling from spec object graph for nulling out [[Target]] #105
The wording around 'field or internal slot' is clarified, resolving review: question about when cleanup is allowed #115