On 03/23/2014 12:17 AM, Boris Zbarsky wrote:
Say we have this:
observerService.addSettingObserver("data-changed", obj, "cache", null)
and someone sets a "data-changed" notification. If I understand your
proposal correctly, that will do some equivalent of "obj.cache = null",
assuming "obj" is still alive, right?
Yes, that's right.
But doing "obj.cache = null" can in fact invoke an arbitrary setter on
obj (and if we use defineProperty, we run into proxies being able to
intercept even that). I guess we could require that "obj" is a
non-proxy object which has "cache" as an own non-configurable writable
data property to remove that hazard?
Yes, we would have to do something like that, to ensure code doesn't run.
The crucial point is: there's no construct that can completely
substitute for weak references that does not itself expose GC
non-determinism. So we must choose some less powerful construct that
still gets the job done. These "setter observers" are one such; I'd
argue that WeakMaps are another example of a deterministic interface
that handles many cases that people used to want weak references for.
But replacing a powerful facility with something, um, weaker, entails
looking back over the details of the problem to see what might suffice.
Sometimes just zapping an outdated cache is good enough; but sometimes
it isn't, so you look for some other limited-but-deterministic construct.
It's worth noting that we're not really *avoiding* GC-sensitivity; we're
just *confining* it. WeakMaps have a very GC-entangled implementation
behind their deterministic interface. And my toy "setter observers"
proposal needs to know about finalization to remove the observers. But
their visible behavior is deterministic.
I'm hoping that, having considered the specifics, the use cases will
fall into two categories:
1) Those where there's some point before finalization at which observers
/ listeners can be removed.
2) Those where a limited-but-deterministic construct could suffice.
These we can then implement in C++, and avoid exporting any new
non-deterministic features to JS. This could require some luck and
creative thinking.
It would be a shame if there were some that fall into the third category:
3) Those where one must run involved application-specific logic at
finalization time, never sooner.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
