In many cases the point at which an object becomes uninteresting is the point at which it is unreachable, and no deterministically identifiable point before that. It is true that in many cases you don't need anything resembling weak references, and can simply manually mark objects as dead. There are many application scenarios, though, where no single component is able to be responsible for managing the lifetime of a given object because the object is manipulated by multiple other objects. In such scenarios nothing short of reference counting (i.e. garbage collection and notification upon the object being unreachable/having no references) will suffice for preventing leaks.
A hypothetical scenario (please ignore any minor detail errors, I'm using this to illustrate the scenario): Let's say I have a main document and it spawns 3 popup windows as documents. The popup windows have references to the parent document and use them to post messages to the parent document for the purposes of collaboration. Now, let's say I want the popups to *keep working* even if the parent document is closed. In this scenario, the popups *need* to retain their references to the parent document, but we don't want to leak the parent document after all 3 of them are closed. This is a scenario you cannot trivially implement without some form of GC notification. If you happen to write everything in C++, then you can be sure you don't need JS-accessible weak references here, but once enough logic lives in JavaScript (say for handling message ports, or releasing image/script resources used by the document, or terminating any playing background audio, or...) it is quite possible that JS will need a way to clean up when an object becomes unreachable. Sometimes these relationships are bidirectional, which makes it difficult to move all the cleanup logic into the target object's onDisposed-equivalent method without forming new cycles. If you want to be able to self-host the vast majority of the web platform and applications in JS, I think it's inevitable that you will need some sort of weak reference equivalent, and this is more or less the conclusion that was reached on es-discuss. Whether it should be what people commonly refer to as 'weak references' or some other abstraction with better properties, I don't know. (I do know that WeakMaps aren't it.) On Fri, Mar 21, 2014 at 7:14 PM, Jim Blandy <j...@mozilla.com> wrote: > On 03/21/2014 05:03 PM, Boris Zbarsky wrote: >> >> On 3/21/14 6:34 PM, Jim Blandy wrote: >> I don't believe there are any DOM nodes involved in the situation that >> Kyle described at the start of this thread... > > > It's true that when I read, "We are discovering a lot of leaks in JS > implemented DOM objects", I wasn't sure what he was referring to... > > But the same question carries over: isn't there some way to tie the > registration / unregistration of observers / listeners to something more > directly connected to the notification recipient becoming uninteresting? > > That is, there's usually some point well before the notification recipient > becomes garbage that it becomes uninteresting. Hence my mention of DOM node > insertion / removal. > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
