Lazy evaluation

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Sep 11 07:33:46 UTC 2017


Using weakmaps has disadvantages if instances are many, due pressure, and
it's also slower than just further property access, requiring a
`wm.get(...)` each time.

On top of that, you workaround the issue, but you don't solve it.

The platform way to solve your issue is the following:

```js
class Foo {
  get bar() {
    if (this.constructor.prototype === this) throw 'unauthorized';
    var result = [];
    Object.defineProperty(this, 'bar', {value: result});
    return result;
  }
}
```

I've used the long check instead of `this === Foo.prototype` because the
condition `this.constructor.prototype` works through inheritance chain too.

I also use a variable and return it instead because not everyone knows that
IE might go in recursion accessing a getter within the getter ;-)

Regards




On Mon, Sep 11, 2017 at 7:06 AM, Michał Wadas <michalwadas at gmail.com> wrote:

> BTW consider this:
>
> ```js
> class Foo {
>   get bar() {
>     Object.defineProperty(this, 'bar', {value: []});
>     return this.bar;
>   }
> }
> const a = new Foo;
> Foo.prototype.bar;
> const b = new Foo;
> const c = new Foo;
> // b.bar === c.bar
> ```
>
> So I recommend this instead:
>
> ```js
> const wm = new WeakMap;
> class Foo {
>   get bar() {
>     if (!wm.has(this)) {
>       wm.set(this, []);
>     }
>     return wm.get(this);
>   }
> }
> const a = new Foo;
> Foo.prototype.bar;
> const b = new Foo;
> const c = new Foo;
> // b.bar !== c.bar
> ```
>
>
> On Fri, Sep 1, 2017 at 12:11 PM, <herby at mailbox.sk> wrote:
>
>>
>>
>> On August 31, 2017 6:15:20 PM GMT+02:00, Isiah Meadows <
>> isiahmeadows at gmail.com> wrote:
>> >Promises are inherently eager, but also async - consider that `new
>> >Promise(resolve => resolve(1))` is roughly equivalent to `var promise
>> >= Promise.resolve(1)`.
>> >
>> >My proposal is for a single immediate value, but created on demand
>> >(when you call `.get()`) rather than immediately.
>>
>> But then, it seems to me Andrea's self-rewriting getter gets to the point.
>>
>> Maybe there can be 'caching' getter planned as in:
>>
>> Object.defineProperty(foo, "bar", {
>>   get: () => "baz",
>>   caching: true
>> });
>>
>> with a shortcut
>>
>> Object.defineLazyValue(
>>   foo, "bar", () => "baz");
>>
>> which is implementable via a lib.
>>
>> Herby
>> >-----
>> >
>> >Isiah Meadows
>> >me at isiahmeadows.com
>> >
>> >Looking for web consulting? Or a new website?
>> >Send me an email and we can get started.
>> >www.isiahmeadows.com
>> >
>> >
>> >On Thu, Aug 31, 2017 at 10:37 AM, Naveen Chawla <naveen.chwl at gmail.com>
>> >wrote:
>> >> Could you not do this with a promise? If not, what's missing in
>> >promise that
>> >> you could do with "lazy"? Sorry if I've missed the whole premise
>> >>
>> >> On Thu, 31 Aug 2017 at 19:09 Andrea Giammarchi
>> ><andrea.giammarchi at gmail.com>
>> >> wrote:
>> >>>
>> >>> the following is how I usually consider lazy values
>> >>>
>> >>> ```js
>> >>> class Any {
>> >>>   _lazy(name) {
>> >>>     switch (name) {
>> >>>       case 'uid': return Math.random();
>> >>>       // others ... eventually
>> >>>     }
>> >>>   }
>> >>>   get uid() {
>> >>>     var value = this._lazy('uid');
>> >>>     // from now on, direct access
>> >>>     Object.defineProperty(this, 'uid', {value});
>> >>>     return value;
>> >>>   }
>> >>> }
>> >>>
>> >>> const a = new Any;
>> >>> a.uid === a.uid; // true
>> >>> ```
>> >>>
>> >>> If I understand correctly your proposal is to use Lazy as generic
>> >>> descriptor, is that correct ?
>> >>>
>> >>> ```js
>> >>> Object.defineProperty({}, 'something', new Lazy(function (val) {
>> >>>   return this.shakaLaka ? val : 'no shakaLaka';
>> >>> }));
>> >>> ```
>> >>>
>> >>> ???
>> >>>
>> >>> If that's the case I see already people confused by arrow function
>> >>> in case they need to access the context,
>> >>> plus no property access optimization once resolved.
>> >>>
>> >>> It's also not clear if such property can be set again later on
>> >(right now
>> >>> it cannot)
>> >>> 'cause lazy definition doesn't always necessarily mean inability to
>> >>> reassign.
>> >>>
>> >>> What am I missing/misunderstanding?
>> >>>
>> >>> Regards
>> >>>
>> >>>
>> >>>
>> >>> On Thu, Aug 31, 2017 at 2:21 PM, Isiah Meadows
>> ><isiahmeadows at gmail.com>
>> >>> wrote:
>> >>>>
>> >>>> It'd be really nice if lazy values made it into the spec somehow.
>> >I've
>> >>>> already found myself using things like this [1] quite a bit, and
>> >I've
>> >>>> also found myself frequently initializing properties not on first
>> >>>> access.
>> >>>>
>> >>>> [1]:
>> >>>>
>> >https://gist.github.com/isiahmeadows/4c0723bdfa555a1c2cb01341b323c3d4
>> >>>>
>> >>>> As for what would be a nice API, maybe something like one of these?
>> >>>>
>> >>>> ```js
>> >>>> class Lazy<T> {
>> >>>>     constructor(init: () => T);
>> >>>>     get(): T; // or error thrown
>> >>>> }
>> >>>>
>> >>>> function lazy<T>(init: () => T): () => T; // or error thrown
>> >>>>
>> >>>> function lazy<T>(init: () => T): {
>> >>>>     get(): T; // or error thrown
>> >>>> }
>> >>>> ```
>> >>>>
>> >>>> Alternatively, syntax might work, with `do` expression semantics:
>> >>>>
>> >>>> ```js
>> >>>> const x = lazy do { ... }
>> >>>> // expose via `x.get()` or just `x()`
>> >>>> ```
>> >>>>
>> >>>> -----
>> >>>>
>> >>>> Isiah Meadows
>> >>>> me at isiahmeadows.com
>> >>>>
>> >>>> Looking for web consulting? Or a new website?
>> >>>> Send me an email and we can get started.
>> >>>> www.isiahmeadows.com
>> >>>> _______________________________________________
>> >>>> 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
>> >_______________________________________________
>> >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
>>
>
>
> _______________________________________________
> 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/20170911/c5b4a77d/attachment.html>


More information about the es-discuss mailing list