[Proposal] New syntax for lazy getters

herby at mailbox.sk herby at mailbox.sk
Tue Jun 12 11:14:23 UTC 2018

On June 12, 2018 9:44:31 AM GMT+02:00, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>My 2 cents,
>I use lazy getters since about ever and I'd love to have such syntax in
>place but I think there is room for some improvement / simplification
>terms of syntax.

Yeah I find this better.

Also fixes the this questions by unambiguously setting it to the instance.

>*## Keep it getish*
>From parsing perspective, introducing `lazy tail()` seems way simpler
>introducing `lazy tail:` for the simple reason that everything that can
>parse `get tail()` and `set tail()` is in place already in every
>engine. I
>don't write them but I'm sure having an extra keyboard to catch
>be crazy complicated.
>*## class compatible*
>because you used `delete this.tail` and mentioned functional
>I'd like to underline ES doesn't force anyone to one programming style
>another. That means new syntax should play nicely with classes too, and
>this case the proposal doesn't seem to address that because of the
>value mutation, as generic property, and the removal of that property
>the object, something not needed if inherited.
>My variant would do the same, except it would keep the value an
>const take = (n, xs) => n === 0 ? null : xs && {
>    head: xs.head,
>    lazy tail() {
>      return Object.defineProperty(this, 'tail', {
>        configurable: false,

Why enforcing configurable false? When you use get x() / set x() syntax, it leaves the thing configurable true. I feel it is more consistent to have the replaced getter copy configurable from existing status quo, that is, what is actual configurable of this.tail.

And of course, Object.defineProperty family needs a way to create this, I think {get: getterFn, lazy: true, …} could work.


>        get: (value =>
>          // still a getter
>          () => value
>        )(
>          // executed once
>          take(n - 1, xs.tail)
>        )
>      }).tail;
>    }
>This would keep initial accessor configuration, in terms of
>but it will freeze its value forever and, on top of that, this will
>already well with current valid ES2015 classes syntax.

More information about the es-discuss mailing list