[proposal] Persistent variables in functions/methods

[Isiah Meadows]

> Well that’s the proposal. In case there’s a confusion with “lifetime”. What
> I meant was that as far as garbage collector is concerned, persistent
> variables live as long as the function is referenced somewhere (unlike
> anonymous functions)

Who says an implementation is actually going to *adhere* to that? As
far as I understand, engines try to merge as many closures as they
can, so this, for example, only forms one closure:

```js
function foo() {
    var counter = 0
    return {
        inc() { counter++ },
        get() { return counter },
    }
}
```

I would expect engines to probably do similar with persistent
variables, just they would probably create a separate closure if it
references nothing else in the immediate parent closure. But unless
you do that for almost all your closure variables, I'm not sure you'd
see any real wins here. On top of that, there's two other issues:

1. GC is usually not a performance issue unless you're dealing with a
*lot* of objects. You won't likely ever hit this unless you're doing a
virtual DOM implementation, a real-time video game, or something
similarly computationally demanding.
2. I have no shortage of criticisms over how *poorly* engines optimize
closures compared to objects. Closures should be simpler and easier to
optimize (it's a function body + phantom `this`, but you know the
shape of it statically), yet somehow they aren't seeing very many of
the optimizations performed on objects? Because of this, I also don't
see static variables out-performing object properties.

------

Separately, I don't really see the benefit of this apart from scoping
and simple caching, and most of the time when it could've been useful,
it's been more useful for me to do one of the following:

1. Break it into a separate module.
2. Create a class for the mess.
3. Create an object for the mess.
4. Some combination of the above.

Each of these helps mitigate the scoping issue, and some of them also
help ease the caching issue by keeping the cache closer to where it's
used.

In my experience, when you start having much of a need of local static
variables, it's usually a good time to consider refactoring the code
so it uses a more structured data representation. It's usually not
hard to restructure it, but it results in code that's much more
predictable and easier to understand. The data model usually ends up
clearer, and it's easier to optimize it. Sometimes, you end up
simplifying, fixing, or optimizing it because when you better
centralize and structure the data types, it becomes easier to spot
things that seem out of place.

-----

Isiah Meadows
me at isiahmeadows.com
www.isiahmeadows.com


On Tue, Jul 17, 2018 at 1:30 AM, Neek Sandhu <neek.sandhu at outlook.com> wrote:
>> RE at jhpratt
>
>
>
> Well that’s the proposal. In case there’s a confusion with “lifetime”. What
> I meant was that as far as garbage collector is concerned, persistent
> variables live as long as the function is referenced somewhere (unlike
> anonymous functions)
>
>
>
> Also revisiting your idea of using static properties instead, how’d you
> imagine static props on methods of classes considering the fact that stuff
> should “live” where it “belongs” and not “leak” out unnecessarily, imagine
> this:
>
>
>
> ```javascript
>
> class DBService {
>
>     foo(uri) {
>
>         persist const httpRE = /^https?/;
>
>         persist let counter = 0;
>
>
>
>         return 0;
>
> }
>
> ```
>
>
>
> In the example above it is given that no other method in `DBService` class
> uses, or has anything to with `counter` “inside” of `DBService#foo`. So
> “leaking” it out is unnecessary
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>