On August 31, 2017 6:15:20 PM GMT+02:00, Isiah Meadows <[email protected]>
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
>[email protected]
>
>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 <[email protected]>
>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
><[email protected]>
>> 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
><[email protected]>
>>> 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
>>>> [email protected]
>>>>
>>>> Looking for web consulting? Or a new website?
>>>> Send me an email and we can get started.
>>>> www.isiahmeadows.com
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [email protected]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>_______________________________________________
>es-discuss mailing list
>[email protected]
>https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
