As far as I understand it, weak references are useful to avoid leaks when you don't know (1) who is referring to you or (2) what your lifetime should be. Revocable proxies are useful to avoid leaks when you don't know (1) but you do know (2). Of course, if you know both, you don't need either.
Andrew ----- Original Message ----- > Moreover, it sounds like revocable proxies can be used by libraries to > achieve the same effects with respect to memory leaks, no? > > > On Mon, Dec 2, 2013 at 12:42 PM, Jason Orendorff > <jorendo...@mozilla.com>wrote: > > > On 12/2/13 2:18 PM, Jason Orendorff wrote: > > > However, I've become unconvinced by the data binding use case. Yehuda > > > Katz and I discussed it, and after some pointed questions, he gave up, > > [...] > > > > The flavor of my pointed questions was like this: Yehuda said that > > WeakRefs would be a feature "for libraries", and that their internal use > > could be hidden from end users. He pointed to Ember bindings > > <http://emberjs.com/guides/object-model/bindings/>. > > > > I think this view, that WeakRef nondeterminism can be hidden from end > > users, is common. > > > > But suppose Ember used WeakRefs to implement Ember bindings. That would > > become visible to end users in the form of things mysteriously no longer > > working after GC. For example, if you have A bound to B which is bound > > to C, and B gets collected, then A and C would no longer be bound to > > each other. > > > > More generally, I think this view is just wrong. Lambda doesn't hide > > general flakiness. Successful use of WeakRefs in pub-sub use cases > > depends on establishing strong references from all downstream objects > > that can observe an event to the event listener. Only the end user can > > know what those downstream objects even are. > > > > Yehuda still wants WeakRefs but is not willing to spend a lot of time on > > a losing battle. > > > > -j > > > > _______________________________________________ > > dev-tech-js-engine-internals mailing list > > dev-tech-js-engine-internals@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > > > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
