What is the status of Weak References?

Owen ellbur at gmail.com
Sat Jul 22 18:22:21 UTC 2017


Thank you for the link, I'm glad to see that people have been making
progress on it.

On Fri, Jul 21, 2017 at 2:16 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> This is probably best asked/stated here:
> https://github.com/tc39/proposal-weakrefs/
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> 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
> > shouldn't.
> >
> > 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
> > shape.
> >
> > 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
> > inside.
> >
> > 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
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170722/aa2c9bc7/attachment.html>


More information about the es-discuss mailing list