[proposal] Persistent variables in functions/methods

Ben Wiley therealbenwiley at gmail.com
Tue Jul 17 06:00:11 UTC 2018


@peter: I think you made some valid point in there but you could have been
more concise and nicer :)
https://www.destroyallsoftware.com/blog/2018/a-case-study-in-not-being-a-jerk-in-open-source

@Neek: worth noting that your compiled example is not semantically
identical to the proposed behavior. In the closure example the persistent
variables are initialized at the time the inner function is defined, not at
the time it is first called. If it's initialized at the time of function
definition then there's no persist access to local variables inside the
function itself (although different than C++, not a bad thing imo!).

Ben


Le mar. 17 juill. 2018 01 h 51, Neek Sandhu <neek.sandhu at outlook.com> a
écrit :

> > re at Ben
>
>
>
>    1. `persist` because didn’t want to bring in the dark connotation
>    associated with `static` variables in C++. Although `persist` is just an
>    example to prove a point, could be anything really (even `static` 😊)
>    2. As for my knowledge and understanding, I’d imagine these to behave
>    just like closures w/ IIFE
>
>
>
> ```javascript
>
> function foo(n) {
>
>     // initialized on first call to foo, persists for subsequent calls
>
>     persist let counter =  0;
>
>
>
>     // this way JS engine won't have to recompile the pattern everytime
>
>     persist const httpRE = /^https?/;
>
>
>
>     counter++;
>
>     return n * a;
>
> }
>
> ```
>
>
>
> is 1:1 as
>
>
>
> ```javascript
>
> let foo = (() => {
>
>     let counter = 0;
>
>     const httpRE = /^https?/;
>
>     return (n) => {
>
>         counter++;
>
>         return  n * a;
>
>     }
>
> })()
>
> ```
>
>
>
> Revisions to this are welcome of course
>
>
>
>
>
>    1. Ref #2
>    2. Umm…. Lets just say the fact we need to preserve state (like
>    `counter` or `lastValue`) is good enough selling point
>    3. This proposal aims for and enforces, once again, the motto that stuff
>    should “live” where it “belongs” and not “leak” out unnecessarily
>    4. Ref #5 and also see my reply to jhpratt that explains how this
>    fails when class methods are in question (see `DBService` class example)
>
>
> _______________________________________________
> 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/20180717/35b1a3f7/attachment.html>


More information about the es-discuss mailing list