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 <[email protected]> wrote: > This is probably best asked/stated here: > https://github.com/tc39/proposal-weakrefs/ > ----- > > Isiah Meadows > [email protected] > > 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 <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
