[proposal] Persistent variables in functions/methods

Peter Jaszkowiak p.jaszkow at gmail.com
Tue Jul 17 05:50:34 UTC 2018

This is just syntactic sugar for existing functionality. It is only useful
for a single use case, one which is generally rare anyways, and easily
accomplished when necessary. It provides like to no benefit in clarity,
concision, or flexibility over existing solutions. It adds another way of
storing state for methods, which is introducing unnecessary ambiguity over
where that state should be stored (as a member of the parent object).

It's also worth mentioning that a more general solution most likely exists
in the proposed addition of decorators.

This proposal is yet another example of niche nice-to-have turned into
generally useless syntax proposal.

On Jul 16, 2018 23:30, "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


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180716/122adbe6/attachment.html>

More information about the es-discuss mailing list