On 03/22/2014 10:43 PM, K. Gadd wrote:
> I'm confused about how this would work. who's observing what? How can
> obj be collected if you're passing it as an argument? This looks like
> a synchronous property set passed through an unnecessary intermediary.
Sorry, my code example was confusingly incomplete. Let me try again:
Some observers simply need to mark some computed state as no longer
being up-to-date (marking a cached result as invalid, say), and it's
fine - preferable, perhaps - for this data to be recomputed the next
time it's requested, not each time the observer is notified. In that
case, a special, limited kind of observer could be enough:
observerService.addSettingObserver("state-changed", obj, "dirty", true)
or
observerService.addSettingObserver("data-changed", obj, "cache", null)
where the "data-changed" notification tells us that some underlying data
has changed, and obj has cached the result of some computation that
depends on that data in its 'cache' property. Sending a "data-changed"
notification zaps obj's cache.
This is certainly a lot less general than a callback function! But in
those cases where it is good enough, the big advantage is that
observerService can use weak references or finalization internally to
remove the observer hen obj goes away, and the effect is completely
invisible to its customers. From the outside, it is a completely
deterministic API.
My general point is: In addition to looking for events other than
finalization to pin cleanups on, we should also look into facilities
less general than callbacks that present deterministic APIs, even if
they use GC-sensitive facilities internally.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
