[Proposal] New syntax for lazy getters

kai zhu kaizhu256 at gmail.com
Wed Jun 27 12:23:09 UTC 2018


> What it's doesn't cover (and in my opinion should be the focus of a new proposal) is Decorators for literal objects. Something like the code below is yet not proposed:
> 
> ``` js
> const foo = {
>   @lazy bar: 3,
> };
> ```

what would happen if you tried to JSON.stringify foo? a core-value of javascript to industry is as an idiot-proof/least-surprise language for serializing json-data across browser <-> server.  junior-programmers who naively employ hard-to-serialize things like custom-getters in their low-level code, mostly end up annoying senior-programmers when they have to debug high-level integration-code that have problems baton-passing those states around.

kai zhu
kaizhu256 at gmail.com



> On 12 Jun 2018, at 9:07 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:
> 
> BTW, I proposed similar (lazy values) 9 months ago [1], and it's been
> on the list plenty of times [2]. I'd personally *love* to see it
> happen, but I find it not very likely it'd make it, especially as a
> property (since decorators can rectify that).
> 
> [1]: https://esdiscuss.org/topic/lazy-evaluation
> [2]: https://www.google.com/search?q=site%3Aesdiscuss.org+lazy+property+OR+getter+OR+setter
> 
> -----
> 
> Isiah Meadows
> me at isiahmeadows.com
> www.isiahmeadows.com
> 
> 
> On Tue, Jun 12, 2018 at 8:48 AM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
>> FWIW, I think to keep it simple `lazy: true` would be enough for the time
>> being.
>> 
>> Having the new descriptor inside the descriptor seems a bit over engineering
>> at this point, imo, but having a field already won't exclude, in the
>> feature, the ability to improve that field (similar way addEventListener on
>> DOM got promoted from `(type, handler, boolean)` signature to `(type,
>> handler, boolean || options)`)
>> 
>> I also agree that `lazy field = expr` is a different beast, and it won't
>> play well with descriptors as we know, but it might allow overwrites if
>> accessed directly.
>> 
>> I wouldn't mind that as long as it plays well with objects and classes, and
>> as long as there is an official way to lazy define properties, and if it
>> could be so lazy that if redefined disappears, in that direct assignment
>> form, it would be a solution to all my cases.
>> 
>> Regards
>> 
>> 
>> On Tue, Jun 12, 2018 at 2:37 PM, <herby at mailbox.sk> wrote:
>>> 
>>> Actually, by malleable I meant only configurable:true, so one can change
>>> it via Object.defineProp… api, I did not mean necessarily to define it as
>>> value.
>>> 
>>> I have no strong opinion on what should be there after the first access,
>>> but it boils down on how will it be exposed via Object.defineProperty,
>>> really, because as little as possible should be changed, IOW as much as
>>> possible retained.
>>> 
>>> So on case things are defined as (only pondering the property descriptor
>>> here, the call is obvious):
>>> 
>>>  { lazy: true, get: () => Math.random() } … [1]
>>> 
>>> or, bigger example:
>>> 
>>>  { lazy: { configurable: false }, enumerable: false, get: () =>
>>> foos.length, set: x => console.log(`set ${x}`) } … [2]
>>> 
>>> Then what should be generated is indeed a getter so that setter may be
>>> retained as well in [2].
>>> 
>>> If the definition is:
>>> 
>>> { lazy: { configurable: false, writable: false, enumerable: true, compute:
>>> () => Math.random() }, enumerable: false } … [3]
>>> 
>>> then it defines a value (which is not enumerable until first accessed thus
>>> created; contrived example, I know).
>>> 
>>> This post also shows a proposal how to, in future proof way, define what
>>> attributes will the replaced getter/value have: put it In lazy field of prop
>>> descriptor, lazy: true means shortcut for “the default way / Inherit from
>>> what is there now”.
>>> 
>>> Herby
>>> 
>>> On June 12, 2018 2:02:28 PM GMT+02:00, Aadit M Shah
>>> <aaditmshah at fastmail.fm> wrote:
>>>> Okay, so my previous statement about field declarations in classes
>>>> being
>>>> invalid was incorrect. I didn't see Andrea's link to the class field
>>>> declarations proposal[1]. Hence, from what I understand we're
>>>> considering the following syntax:
>>>> const zeros = { head: , lazy tail: this };
>>>> 
>>>> class Random {
>>>>   lazy value = Math.random();
>>>> }
>>>> 
>>>> As for semantics, Herby's philosophy of "malleable unless specified
>>>> otherwise" makes sense. Hence, the above code would be transpiled to:
>>>> const zeros = {
>>>>   head: ,
>>>>   get tail() {
>>>>       return Object.defineProperty(this, "tail", {
>>>>           value: this
>>>>       }).tail;
>>>>   }
>>>> };
>>>> 
>>>> class Random {
>>>>   get value() {
>>>>       return Object.defineProperty(this, "value", {
>>>>           value: Math.random()
>>>>       }).value;
>>>>   }
>>>> }
>>>> 
>>>> I guess we'd also be adopting the syntax for private fields and static
>>>> fields? For example, lazy #value and lazy static #value?
>>>> 
>>>> On Tue, Jun 12, 2018, at 7:32 AM, herby at mailbox.sk wrote:
>>>>> 
>>>>> 
>>>>> On June 12, 2018 11:32:22 AM GMT+02:00, Aadit M Shah
>>>>> <aaditmshah at fastmail.fm> wrote:>> 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;    } };
>>>>> 
>>>>> I am pretty sure Andrea mixed syntax of lazy getter with its
>>>>> implementation for brevity, and the actual lazy getter would
>>>>> look like:>
>>>>>  lazy tail() { return take(n - 1, xs.tail); }
>>>>> 
>>>>>> 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.
>>>>> 
>>>>> Here I disagree. No syntax construct so far forces immutability. The
>>>>> get x() / set x() ones are configurable. If you defined lazy getter
>>>>> so far by get(), you could have changed it using
>>>>> Object.defineProperties if there was some strange need for it. You
>>>>> had to explicitly freeze etc. or defineProperty with configurable
>>>>> false if you wanted to make it so.>
>>>>> This autofreezing if the value sticks out out this philosophy of "
>>>>> malleable unless specified otherwise".>
>>>>>> 
>>>>>> 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
>>>>>>> <aaditmshah at 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 at 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
>>>> 
>>>> Links:
>>>> 
>>>> 1. https://github.com/tc39/proposal-class-fields#field-declarations
>> 
>> 
>> 
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>> 
> _______________________________________________
> 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/20180627/671afd81/attachment-0001.html>


More information about the es-discuss mailing list