Le 02/12/2013 23:44, Andrew McCreight a écrit :
As far as I understand it, weak references are useful to avoid leaks when you
don't know (1) who is referring to you
From what I understand of Object Capabilities, in memory-safe
languages, someone has a reference to an object only if one of these
happened:
1) this party had a reference at t0
2) this party was given a reference to this object
3) this party created the object
(I think there is a 4th case but can't remember now, but I don't think
it questions my point thereafter)
If you create an object (usually how memory leaks start :-p), you're
initially the only party with a reference to it and you get to choose
who you share the object with as well as if you want to share a
reference to the object or a proxy. From this flows that you're always
in control of who has access directly to the object (this control
involves trusting 3rd-parties, but the point remains).
My point being that in JS, it's possible to work your program so that
not knowing who is referring to a given object you created doesn't happen.
David
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
<[email protected]>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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
