What is the status of Weak References?
isiahmeadows at gmail.com
Fri Jul 21 18:16:26 UTC 2017
This is probably best asked/stated here:
me at isiahmeadows.com
Looking for web consulting? Or a new website?
Send me an email and we can get started.
On Thu, Jul 20, 2017 at 6:26 PM, Owen <ellbur at gmail.com> wrote:
> I see this is a very old thread, but I was wondering if there have been any
> new developments/plans?
> My thoughts are this:
> I think it's natural, if you're used to seeing people misuse GC, to be
> suspicious of weakrefs. With GC it's easy to create accidental memory leaks
> because you think the useful lifetime of your objects will always correspond
> to the lifetime of their references, when in fact they don't. My Java code
> always has more memory leaks than my C++ code, even though they tell me it
> But in my experience people don't tend to misuse weakrefs. Weakrefs are
> tricky and awkward, so they're not a tempting feature; people don't tend to
> use them unless they have a specific compelling need. They're not a feature
> like C++ implicit conversions where everyone uses them and then shoots them
> in the foot. So I think the risk of adding weakrefs to the language from a
> code maintainability perspective are fairly low.
> I think the one-time-listener pattern is really great. I've written some FRP
> code that uses it, and it makes a whole lot of things better, such as
> skipping over unnecessary calculations and handling listeners that return
> listeners gracefully. But it turns out it doesn't solve the memory problem
> unless you also have weakrefs. The reason is that it's far more common than
> you might think to create listeners that are never ever called. Think about
> opening a dialog with OK and Cancel buttons, listening on each. Every time
> you open the dialog, at least one listener will leak. What
> one-time-listeners does solve very nicely is the lifetime of control -- you
> can trust that the code associated with useless listeners will never be
> called, and never waste CPU cycles. But unfortunately the memory stays
> around unless you have weakrefs.
> We must remember that our programming languages are Turing complete, so that
> everything that can be done with weakrefs can also be done without them. It
> might seem sort of like asking MS Paint to expose its flood-fill algorithm
> through an API -- because you know it's in there, and maybe you want to use
> it in your code and avoid duplication. Well, that would seem rather silly,
> asking MS Paint to expose an API -- go use your own flood-fill algorithm!
> And maybe that's what it seems like with the GC -- just because the GC is
> there, doesn't mean it has to make all its features available to the
> programmer to do what they like with.
> It's just that it happens that implementing GC is just such a massive and
> tricky task, that it's just *so* *tempting* to use the GC that's already
> there. It can solve certain problems for you so that you don't have to solve
> them yourself. It doesn't solve every problem -- no software can -- but when
> it does solve one of your problems it solves it so beautifully. And it's
> just so frustrating to know the code is right there under the surface and
> you can't use it. Sure, maybe you should do the memory management yourself.
> But if you could just get at those weakrefs..... then you'd be in good
> In my experience there is a very small set of problems that really really
> benefit from weakrefs. Most of the code you write will never encounter one
> of those problems. But when you do hit one, it's so nice when the language
> supports it. You write your weakref code carefully -- because it's
> nondeterministic and hard to debug. You box it in real tight and get a solid
> core that uses weakrefs just the way you need it. Then you expose it as a
> library and never think about it again. You make sure the semantics of your
> library never expose a nondeterministic variable -- those stay on the
> The funny thing is that even when you keep your API fully deterministic, the
> fact that it can use the GC's nondeterminism on the inside changes what the
> external API can do. It's like how using a nonlinear electrical component
> can change the set of linear transfer functions you can implement at the
> boundary. And because everyone wants to work with nice APIs at the boundary,
> there's very little temptation to abuse weakrefs.
> Just some things to consider.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss