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.san...@outlook.com> wrote:
> RE@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
