Actually, from a parsing perspective I believe it shouldn't be too
difficult to implement the `lazy name: expression` syntax. In
addition, I'm not too keen on your `lazy name() { return expression;
}` syntax because:
1. It's more verbose.
2. It seems to me that it's no different than creating a regular
getter:
const take = (n, xs) => n === ? null : xs && { head: xs.head, get
tail() { const value = take(n - 1, xs.tail);
Object.defineProperty(this, "tail", { configurable: false,
get: () => value }); return value; } };
Regarding the second bullet point, I've probably misunderstood what you
were trying to convey. Perhaps you could elucidate.
Anyway, making the property non-configurable after accessing it seems
like a reasonable thing to do.
On Tue, Jun 12, 2018, at 3:44 AM, Andrea Giammarchi 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 in terms of syntax.>
> *## Keep it get*ish**
>
> From parsing perspective, introducing `lazy tail()` seems way simpler
> than 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 shouldn't be crazy complicated.>
> *## class compatible*
>
> because you used `delete this.tail` and mentioned functional
> programming, I'd like to underline ES doesn't force anyone to one
> programming style or another. That means new syntax should play nicely
> with classes too, and in this case the proposal doesn't seem to
> address that because of the direct value mutation, as generic
> property, and the removal of that property from the object, something
> not needed if inherited.>
> My variant would do the same, except it would keep the value an
> accessor:>
> ```js
> const take = (n, xs) => n === 0 ? null : xs && {
> head: xs.head,
> lazy tail() {
> return Object.defineProperty(this, 'tail', {
> configurable: false,
> get: (value =>
> // still a getter
> () => value
> )(
> // executed once
> take(n - 1, xs.tail)
> )
> }).tail;
> }
> };
> ```
>
> This would keep initial accessor configuration, in terms of
> enumerability, but it will freeze its value forever and, on top of
> that, this will play already well with current valid ES2015
> classes syntax.>
> I also believe myself proposed something similar a while ago (or
> somebody else and I agreed with that proposal) but for some reason it
> never landed.>
> Hopefully this time the outcome would be different.
>
> Best Regards
>
>
>
>
> On Tue, Jun 12, 2018 at 9:13 AM, Aadit M Shah
> <aaditms...@fastmail.fm> wrote:>> __
>> Hello TC39,
>>
>> I recently opened an issue[1] in the tc39/ecma262[2] repository,
>> proposing a new syntax for lazy getters, and I was directed to the
>> CONTRIBUTING[3] page which stated that I should start a conversation
>> on this mailing list.>>
>> So, my feature proposal is to have syntactic sugar for creating lazy
>> getters[4]. To summarize my original proposal (which you can read by
>> following the very first link above), I find that creating lazy
>> getters is very verbose. For example, consider:>>
>> const take = (n, xs) => n === ? null : xs && {
>> head: xs.head,
>> get tail() {
>> delete this.tail;
>> return this.tail = take(n - 1, xs.tail);
>> }
>> };
>>
>> My proposed solution is to add a new keyword lazy to the language.
>> This keyword can only be used as a prefix to longhand property names
>> in object initializers, and it defers the execution of the value
>> expression until the property is accessed. In short, it's just
>> syntactic sugar for lazy getters:>>
>> const take = (n, xs) => n === ? null : xs && {
>> head: xs.head,
>> lazy tail: take(n - 1, xs.tail)
>> };
>>
>> This is purely syntactic sugar. The semantics of this new syntax
>> would remain the same as that of the desugared syntax. In particular,
>> calling Object.getOwnPropertyDescriptor(list, "tail") would return an
>> accessor descriptor before accessing list.tail and a data descriptor
>> afterwards.>>
>> Furthermore, there are other advantages of having this syntactic
>> sugar. For example, creating cyclic data structures becomes much
>> easier. Examples are provided in my original proposal which is linked
>> above. Hope to hear your thoughts on this.>>
>> Regards,
>> Aadit M Shah
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
Links:
1. https://github.com/tc39/ecma262/issues/1223
2. https://github.com/tc39/ecma262
3. https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md
4.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get#Smart_self-overwriting_lazy_getters
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
