Re: Mixing grammars
Ah, I see where you're coming from now. Thanks for the clarification! There has recently been some discussion about the semantics of `|>` in [1]. I think what you're looking for is [2], perhaps? [1] https://github.com/tc39/proposal-pipeline-operator/issues/50 [2] https://github.com/TheNavigateur/proposal-pipeline-operator-for-function-composition On Friday, September 1, 2017 1:52:31 PM CEST Peter van der Zee wrote: > > Sorry, but your message looks very opinionated and I can't seem to find > > any > > objective reasoning in there. > > Nah, you might be thrown off by the different grammar ;) > > Ok. > > Thing is, `|>` would introduce a new way of calling a function in a > way that is not at all in line with how functions are called in JS. > That means JS devs won't easily recognize `a |> b` as easily as they > do `b(a)`. (Also consider less text-book-y examples here please...) > > You might argue that this will be a transitional period and I will > counter you with an existential question; Why at all? What does this > solve? And is it worth the cognitive overhead? > > I think this is a bad addition to the language. One that doesn't "fit" > with how the language currently works. And one that will lead to many > devs being thoroughly confused when confronted with this. > > But, I'm not asking you to take my opinion on it. Research it. Please > do some research on this. Reach out to devs of all types (not just > react devs, not just functional programmers, not just vanilla JS > coders, not just code golfers, and definitely not just people on the > TC39) and figure out how they will respond when confronted with > additions like this. And please post those results here. I don't mind > being wrong. As long as you can back those claims up when introducing > something like this. > > - peter signature.asc Description: This is a digitally signed message part. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mixing grammars
> Sorry, but your message looks very opinionated and I can't seem to find any objective reasoning in there. Nah, you might be thrown off by the different grammar ;) Ok. Thing is, `|>` would introduce a new way of calling a function in a way that is not at all in line with how functions are called in JS. That means JS devs won't easily recognize `a |> b` as easily as they do `b(a)`. (Also consider less text-book-y examples here please...) You might argue that this will be a transitional period and I will counter you with an existential question; Why at all? What does this solve? And is it worth the cognitive overhead? I think this is a bad addition to the language. One that doesn't "fit" with how the language currently works. And one that will lead to many devs being thoroughly confused when confronted with this. But, I'm not asking you to take my opinion on it. Research it. Please do some research on this. Reach out to devs of all types (not just react devs, not just functional programmers, not just vanilla JS coders, not just code golfers, and definitely not just people on the TC39) and figure out how they will respond when confronted with additions like this. And please post those results here. I don't mind being wrong. As long as you can back those claims up when introducing something like this. - peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Mixing grammars
Sorry, but your message looks very opinionated and I can't seem to find any objective reasoning in there. Would you be willing to discuss what exactly you consider the repercussions to be? Many functional languages allow function chaining, some even with a similar syntax. F# features pipe operators as well (in fact, it even features a literal `|>` operator), and Haskell has `.` and `>>>`. ECMAScript has many functional parts. So why not offer better support for FP? On Friday, September 1, 2017 12:54:20 PM CEST Peter van der Zee wrote: > I want quickly a point to make. I have a while ago of the, well, I > know actually not how that thing is called, but the "|> operator" > heard. I ignored it as "funny but a very different paradigm than JS". > > Now see I today a tweet pass by that somebody a draft of a propasal > has created [1] to this really to JS to add. > > I think that it a bad idea is and hope really that the TC39 first a > good research does to the desirability and repercussions of the adding > of similar syntax to the language. > > For me is it just like you the Dutch grammar apply on the English. > Like this message tries to show. You. > > - peter > > > 1; https://github.com/tc39/proposal-pipeline-operator/issues/52 > > > === > > (Dutch) > > Ik wil even een punt maken. Ik heb een tijdje geleden van de, tja, ik > weet eigenlijk niet hoe dat ding heet, maar de "|> operator" gehoord. > Ik deed het af als "grappig maar een heel ander paradigma dan JS". > > Nou zag ik vandaag een tweet voorbij komen dat iemand een draft van > een proposal heeft opgesteld [1] om dit daadwerkelijk aan JS toe te > voegen. > > Ik denk dat het een slecht idee is en hoop echt dat de TC39 eerst een > goed onderzoek doet naar de wenselijkheid en gevolgen van het > toevoegen van dergelijke syntax aan de taal. > > Voor mij is het net alsof je de Nederlandse grammatica toepast op het > Engels. Zoals dit bericht probeert aan te tonen. > > - peter > > > 1; https://github.com/tc39/proposal-pipeline-operator/issues/52 > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss signature.asc Description: This is a digitally signed message part. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Mixing grammars
I want quickly a point to make. I have a while ago of the, well, I know actually not how that thing is called, but the "|> operator" heard. I ignored it as "funny but a very different paradigm than JS". Now see I today a tweet pass by that somebody a draft of a propasal has created [1] to this really to JS to add. I think that it a bad idea is and hope really that the TC39 first a good research does to the desirability and repercussions of the adding of similar syntax to the language. For me is it just like you the Dutch grammar apply on the English. Like this message tries to show. You. - peter 1; https://github.com/tc39/proposal-pipeline-operator/issues/52 === (Dutch) Ik wil even een punt maken. Ik heb een tijdje geleden van de, tja, ik weet eigenlijk niet hoe dat ding heet, maar de "|> operator" gehoord. Ik deed het af als "grappig maar een heel ander paradigma dan JS". Nou zag ik vandaag een tweet voorbij komen dat iemand een draft van een proposal heeft opgesteld [1] om dit daadwerkelijk aan JS toe te voegen. Ik denk dat het een slecht idee is en hoop echt dat de TC39 eerst een goed onderzoek doet naar de wenselijkheid en gevolgen van het toevoegen van dergelijke syntax aan de taal. Voor mij is het net alsof je de Nederlandse grammatica toepast op het Engels. Zoals dit bericht probeert aan te tonen. - peter 1; https://github.com/tc39/proposal-pipeline-operator/issues/52 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Lazy evaluation
On August 31, 2017 6:15:20 PM GMT+02:00, Isiah Meadows
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
>m...@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
>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
>
>> 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
>
>>> 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 {
constructor(init: () => T);
get(): T; // or error thrown
}
function lazy(init: () => T): () => T; // or error thrown
function lazy(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
m...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>___
>es-discuss mailing list
>es-discuss@mozilla.org
>https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Lazy evaluation
then yes, decorators solve my use case pretty well.
```js
const lazy = (Class, prop, desc) => {
var get = desc.get;
desc.get = function () {
var result = get.apply(this, arguments);
Object.defineProperty(this, prop, {value: result});
return result;
};
};
class A {
@lazy
get random() { return Math.random(); }
}
let a = new A;
a.random === a.random; // true
```
On Fri, Sep 1, 2017 at 8:16 AM, Michał Wadas wrote:
> Stage 2, but they move really slow.
>
> On 1 Sep 2017 9:15 am, "Andrea Giammarchi"
> wrote:
>
>> I thought decorators were nowhere higher than stage 0 (since ever)
>>
>> On Thu, Aug 31, 2017 at 9:53 PM, Michał Wadas
>> wrote:
>>
>>> Why not something like decorators (not sure if decorator proposal
>>> covers this already)?
>>>
>>> class Foo {
>>> @cached
>>> get bar() {
>>> return something(this);
>>> }
>>> }
>>>
>>> On 31 Aug 2017 10:30 pm, "Andrea Giammarchi" <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>> it's a matter of semantics.
>>>
>>> If I see this
>>>
>>> ```js
>>> var later = anyWrappingName(() => Math.random());
>>>
>>> // this is an assumption, not something obvious
>>> later() === later()
>>> ```
>>>
>>> If instead, I write this:
>>> ```js
>>> this.later === this.later;
>>> ```
>>>
>>> I expect that to never possibly fail like `arr.length === arr.length` or
>>> any `obj.prop`, in APIs with common sense, are equal to `obj.prop`.
>>>
>>> Invokes via instances and objects? It's never obvious at first look, if
>>> that is a method execution, but it's surely a new invoke.
>>>
>>> If you've trapped once the result behind the scene, reading that, is
>>> just noise for anyone eyes.
>>>
>>> So, once again, are we proposing something that results into exactly
>>> this?
>>>
>>> ```js
>>> class Later {
>>> get thing() {
>>> return Object.defineProperty(this, 'thing', {value: anyLazy()});
>>> }
>>> constructor() {
>>> // always true, no matter when/where
>>> this.thing === this.thing;
>>> }
>>> }
>>> ```
>>>
>>> If so, I'm happy. If not, this is confusing and solving not much.
>>>
>>>
>>> Best Regards
>>>
>>>
>>> On Thu, Aug 31, 2017 at 9:14 PM, Isiah Meadows
>>> wrote:
>>>
Yes. I'll point out that having it as a function, rather than a
property-specific thing, makes it more flexible, since you can define
constants as lazy values (I do that in quite a few places).
If you want to make it transparent, it's not that hard to make a
single-line getter/method that hides the abstraction.
Granted, most of my lazy values are properties, not constants, so I
could consider it an acceptable compromise.
-
Isiah Meadows
m...@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 3:54 PM, Andrea Giammarchi
wrote:
> so in JavaScript that results into this._db() each time, resolved
lazily
> with the first value returned once ?
>
> I still think my approach is cleaner and more transparent.
>
> `get _thing() { return defineProperty(this, 'thing', value) }`
>
> but if your TS-ish stuff translates into that, works for me
>
>
>
> On Thu, Aug 31, 2017 at 8:49 PM, Isiah Meadows <
isiahmead...@gmail.com>
> wrote:
>>
>> It takes a function, and returns a function that (if necessary)
>> initializes the value and then gets it.
>> -
>>
>> Isiah Meadows
>> m...@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 3:43 PM, Andrea Giammarchi
>> wrote:
>> > Sorry I don't speak TS, I speak ES.
>> >
>> > Can you please tell me in JavaScript what does that do?
>> >
>> > On Thu, Aug 31, 2017 at 8:18 PM, Isiah Meadows <
isiahmead...@gmail.com>
>> > wrote:
>> >>
>> >> Note the TS-ish declaration above it. That's the variant I was
>> >> referring to (I presented about 3 different variants initially).
>> >>
>> >> ```ts
>> >> // The declaration I included
>> >> declare function lazy(init: () => T): () => T;
>> >> ```
>> >>
>> >>
>> >> On Thu, Aug 31, 2017 at 3:05 PM, Andrea Giammarchi
>> >> wrote:
>> >> > it wouldn't work, would it ? I mean, you still have to pass
through
>> >> > the
>> >> > "ugly" _db.get() thingy, right?
>> >> >
>> >> > how do you access and trigger the lazy bit within the class?
>> >> >
>> >> > On Thu, Aug 31, 2017 at 7:56 PM, Isiah Meadows
>> >> >
>> >> > wrote:
>> >> >>
>> >> >> What about this (using the stage 3 class fields proposal)?
>> >> >>
>> >> >> ```js
>> >> >> declare function lazy(init: () => T): () => T;
>> >> >>
Re: Lazy evaluation
Just so that there is no confusion: There's also function expression
decorators and method parameter decorators, both of which stage 0.
On Friday, September 1, 2017 9:16:55 AM CEST Michał Wadas wrote:
> Stage 2, but they move really slow.
>
> On 1 Sep 2017 9:15 am, "Andrea Giammarchi"
>
> wrote:
> > I thought decorators were nowhere higher than stage 0 (since ever)
> >
> > On Thu, Aug 31, 2017 at 9:53 PM, Michał Wadas
> >
> > wrote:
> >> Why not something like decorators (not sure if decorator proposal covers
> >> this already)?
> >>
> >> class Foo {
> >> @cached
> >> get bar() {
> >> return something(this);
> >> }
> >> }
> >>
> >> On 31 Aug 2017 10:30 pm, "Andrea Giammarchi"
> >>
> >> wrote:
> >>
> >> it's a matter of semantics.
> >>
> >> If I see this
> >>
> >> ```js
> >> var later = anyWrappingName(() => Math.random());
> >>
> >> // this is an assumption, not something obvious
> >> later() === later()
> >> ```
> >>
> >> If instead, I write this:
> >> ```js
> >> this.later === this.later;
> >> ```
> >>
> >> I expect that to never possibly fail like `arr.length === arr.length` or
> >> any `obj.prop`, in APIs with common sense, are equal to `obj.prop`.
> >>
> >> Invokes via instances and objects? It's never obvious at first look, if
> >> that is a method execution, but it's surely a new invoke.
> >>
> >> If you've trapped once the result behind the scene, reading that, is just
> >> noise for anyone eyes.
> >>
> >> So, once again, are we proposing something that results into exactly
> >> this?
> >>
> >> ```js
> >> class Later {
> >>
> >> get thing() {
> >>
> >> return Object.defineProperty(this, 'thing', {value: anyLazy()});
> >>
> >> }
> >> constructor() {
> >>
> >> // always true, no matter when/where
> >> this.thing === this.thing;
> >>
> >> }
> >>
> >> }
> >> ```
> >>
> >> If so, I'm happy. If not, this is confusing and solving not much.
> >>
> >>
> >> Best Regards
> >>
> >>
> >> On Thu, Aug 31, 2017 at 9:14 PM, Isiah Meadows
> >>
> >> wrote:
> >>> Yes. I'll point out that having it as a function, rather than a
> >>> property-specific thing, makes it more flexible, since you can define
> >>> constants as lazy values (I do that in quite a few places).
> >>>
> >>> If you want to make it transparent, it's not that hard to make a
> >>> single-line getter/method that hides the abstraction.
> >>>
> >>> Granted, most of my lazy values are properties, not constants, so I
> >>> could consider it an acceptable compromise.
> >>> -
> >>>
> >>> Isiah Meadows
> >>> m...@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 3:54 PM, Andrea Giammarchi
> >>>
> >>> wrote:
> >>> > so in JavaScript that results into this._db() each time, resolved
> >>>
> >>> lazily
> >>>
> >>> > with the first value returned once ?
> >>> >
> >>> > I still think my approach is cleaner and more transparent.
> >>> >
> >>> > `get _thing() { return defineProperty(this, 'thing', value) }`
> >>> >
> >>> > but if your TS-ish stuff translates into that, works for me
> >>> >
> >>> >
> >>> >
> >>> > On Thu, Aug 31, 2017 at 8:49 PM, Isiah Meadows >>> >
> >>> > wrote:
> >>> >> It takes a function, and returns a function that (if necessary)
> >>> >> initializes the value and then gets it.
> >>> >> -
> >>> >>
> >>> >> Isiah Meadows
> >>> >> m...@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 3:43 PM, Andrea Giammarchi
> >>> >>
> >>> >> wrote:
> >>> >> > Sorry I don't speak TS, I speak ES.
> >>> >> >
> >>> >> > Can you please tell me in JavaScript what does that do?
> >>> >> >
> >>> >> > On Thu, Aug 31, 2017 at 8:18 PM, Isiah Meadows <
> >>>
> >>> isiahmead...@gmail.com>
> >>>
> >>> >> > wrote:
> >>> >> >> Note the TS-ish declaration above it. That's the variant I was
> >>> >> >> referring to (I presented about 3 different variants initially).
> >>> >> >>
> >>> >> >> ```ts
> >>> >> >> // The declaration I included
> >>> >> >> declare function lazy(init: () => T): () => T;
> >>> >> >> ```
> >>> >> >>
> >>> >> >>
> >>> >> >> On Thu, Aug 31, 2017 at 3:05 PM, Andrea Giammarchi
> >>> >> >>
> >>> >> >> wrote:
> >>> >> >> > it wouldn't work, would it ? I mean, you still have to pass
> >>>
> >>> through
> >>>
> >>> >> >> > the
> >>> >> >> > "ugly" _db.get() thingy, right?
> >>> >> >> >
> >>> >> >> > how do you access and trigger the lazy bit within the class?
> >>> >> >> >
> >>> >> >> > On Thu, Aug 31, 2017 at 7:56 PM, Isiah Meadows
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > wrote:
> >>> >> >> >> What about this (using the stage 3 class fields proposal)?
> >>> >> >> >>
> >>> >> >> >> ```js
> >>> >> >> >> declare function lazy(init: () => T): () => T;
> >>> >>
Re: Lazy evaluation
Stage 2, but they move really slow.
On 1 Sep 2017 9:15 am, "Andrea Giammarchi"
wrote:
> I thought decorators were nowhere higher than stage 0 (since ever)
>
> On Thu, Aug 31, 2017 at 9:53 PM, Michał Wadas
> wrote:
>
>> Why not something like decorators (not sure if decorator proposal covers
>> this already)?
>>
>> class Foo {
>> @cached
>> get bar() {
>> return something(this);
>> }
>> }
>>
>> On 31 Aug 2017 10:30 pm, "Andrea Giammarchi"
>> wrote:
>>
>> it's a matter of semantics.
>>
>> If I see this
>>
>> ```js
>> var later = anyWrappingName(() => Math.random());
>>
>> // this is an assumption, not something obvious
>> later() === later()
>> ```
>>
>> If instead, I write this:
>> ```js
>> this.later === this.later;
>> ```
>>
>> I expect that to never possibly fail like `arr.length === arr.length` or
>> any `obj.prop`, in APIs with common sense, are equal to `obj.prop`.
>>
>> Invokes via instances and objects? It's never obvious at first look, if
>> that is a method execution, but it's surely a new invoke.
>>
>> If you've trapped once the result behind the scene, reading that, is just
>> noise for anyone eyes.
>>
>> So, once again, are we proposing something that results into exactly this?
>>
>> ```js
>> class Later {
>> get thing() {
>> return Object.defineProperty(this, 'thing', {value: anyLazy()});
>> }
>> constructor() {
>> // always true, no matter when/where
>> this.thing === this.thing;
>> }
>> }
>> ```
>>
>> If so, I'm happy. If not, this is confusing and solving not much.
>>
>>
>> Best Regards
>>
>>
>> On Thu, Aug 31, 2017 at 9:14 PM, Isiah Meadows
>> wrote:
>>
>>> Yes. I'll point out that having it as a function, rather than a
>>> property-specific thing, makes it more flexible, since you can define
>>> constants as lazy values (I do that in quite a few places).
>>>
>>> If you want to make it transparent, it's not that hard to make a
>>> single-line getter/method that hides the abstraction.
>>>
>>> Granted, most of my lazy values are properties, not constants, so I
>>> could consider it an acceptable compromise.
>>> -
>>>
>>> Isiah Meadows
>>> m...@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 3:54 PM, Andrea Giammarchi
>>> wrote:
>>> > so in JavaScript that results into this._db() each time, resolved
>>> lazily
>>> > with the first value returned once ?
>>> >
>>> > I still think my approach is cleaner and more transparent.
>>> >
>>> > `get _thing() { return defineProperty(this, 'thing', value) }`
>>> >
>>> > but if your TS-ish stuff translates into that, works for me
>>> >
>>> >
>>> >
>>> > On Thu, Aug 31, 2017 at 8:49 PM, Isiah Meadows >> >
>>> > wrote:
>>> >>
>>> >> It takes a function, and returns a function that (if necessary)
>>> >> initializes the value and then gets it.
>>> >> -
>>> >>
>>> >> Isiah Meadows
>>> >> m...@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 3:43 PM, Andrea Giammarchi
>>> >> wrote:
>>> >> > Sorry I don't speak TS, I speak ES.
>>> >> >
>>> >> > Can you please tell me in JavaScript what does that do?
>>> >> >
>>> >> > On Thu, Aug 31, 2017 at 8:18 PM, Isiah Meadows <
>>> isiahmead...@gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> Note the TS-ish declaration above it. That's the variant I was
>>> >> >> referring to (I presented about 3 different variants initially).
>>> >> >>
>>> >> >> ```ts
>>> >> >> // The declaration I included
>>> >> >> declare function lazy(init: () => T): () => T;
>>> >> >> ```
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Aug 31, 2017 at 3:05 PM, Andrea Giammarchi
>>> >> >> wrote:
>>> >> >> > it wouldn't work, would it ? I mean, you still have to pass
>>> through
>>> >> >> > the
>>> >> >> > "ugly" _db.get() thingy, right?
>>> >> >> >
>>> >> >> > how do you access and trigger the lazy bit within the class?
>>> >> >> >
>>> >> >> > On Thu, Aug 31, 2017 at 7:56 PM, Isiah Meadows
>>> >> >> >
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> What about this (using the stage 3 class fields proposal)?
>>> >> >> >>
>>> >> >> >> ```js
>>> >> >> >> declare function lazy(init: () => T): () => T;
>>> >> >> >>
>>> >> >> >> class WithLazyVals {
>>> >> >> >> _db = lazy(() => new Promise(...));
>>> >> >> >> }
>>> >> >> >> ```
>>> >> >> >> -
>>> >> >> >>
>>> >> >> >> Isiah Meadows
>>> >> >> >> m...@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 1:34 PM, Andrea Giammarchi
>>> >> >> >> wrote:
>>> >> >> >> >> this proposal doesn't compose well with classes
>>> >> >> >> >
>>> >> >> >> > to expand a little, if you were proposing
>>> >> >> >> >
>>> >> >> >> > ```js
>>>
Re: Lazy evaluation
I thought decorators were nowhere higher than stage 0 (since ever)
On Thu, Aug 31, 2017 at 9:53 PM, Michał Wadas wrote:
> Why not something like decorators (not sure if decorator proposal covers
> this already)?
>
> class Foo {
> @cached
> get bar() {
> return something(this);
> }
> }
>
> On 31 Aug 2017 10:30 pm, "Andrea Giammarchi"
> wrote:
>
> it's a matter of semantics.
>
> If I see this
>
> ```js
> var later = anyWrappingName(() => Math.random());
>
> // this is an assumption, not something obvious
> later() === later()
> ```
>
> If instead, I write this:
> ```js
> this.later === this.later;
> ```
>
> I expect that to never possibly fail like `arr.length === arr.length` or
> any `obj.prop`, in APIs with common sense, are equal to `obj.prop`.
>
> Invokes via instances and objects? It's never obvious at first look, if
> that is a method execution, but it's surely a new invoke.
>
> If you've trapped once the result behind the scene, reading that, is just
> noise for anyone eyes.
>
> So, once again, are we proposing something that results into exactly this?
>
> ```js
> class Later {
> get thing() {
> return Object.defineProperty(this, 'thing', {value: anyLazy()});
> }
> constructor() {
> // always true, no matter when/where
> this.thing === this.thing;
> }
> }
> ```
>
> If so, I'm happy. If not, this is confusing and solving not much.
>
>
> Best Regards
>
>
> On Thu, Aug 31, 2017 at 9:14 PM, Isiah Meadows
> wrote:
>
>> Yes. I'll point out that having it as a function, rather than a
>> property-specific thing, makes it more flexible, since you can define
>> constants as lazy values (I do that in quite a few places).
>>
>> If you want to make it transparent, it's not that hard to make a
>> single-line getter/method that hides the abstraction.
>>
>> Granted, most of my lazy values are properties, not constants, so I
>> could consider it an acceptable compromise.
>> -
>>
>> Isiah Meadows
>> m...@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 3:54 PM, Andrea Giammarchi
>> wrote:
>> > so in JavaScript that results into this._db() each time, resolved lazily
>> > with the first value returned once ?
>> >
>> > I still think my approach is cleaner and more transparent.
>> >
>> > `get _thing() { return defineProperty(this, 'thing', value) }`
>> >
>> > but if your TS-ish stuff translates into that, works for me
>> >
>> >
>> >
>> > On Thu, Aug 31, 2017 at 8:49 PM, Isiah Meadows
>> > wrote:
>> >>
>> >> It takes a function, and returns a function that (if necessary)
>> >> initializes the value and then gets it.
>> >> -
>> >>
>> >> Isiah Meadows
>> >> m...@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 3:43 PM, Andrea Giammarchi
>> >> wrote:
>> >> > Sorry I don't speak TS, I speak ES.
>> >> >
>> >> > Can you please tell me in JavaScript what does that do?
>> >> >
>> >> > On Thu, Aug 31, 2017 at 8:18 PM, Isiah Meadows <
>> isiahmead...@gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Note the TS-ish declaration above it. That's the variant I was
>> >> >> referring to (I presented about 3 different variants initially).
>> >> >>
>> >> >> ```ts
>> >> >> // The declaration I included
>> >> >> declare function lazy(init: () => T): () => T;
>> >> >> ```
>> >> >>
>> >> >>
>> >> >> On Thu, Aug 31, 2017 at 3:05 PM, Andrea Giammarchi
>> >> >> wrote:
>> >> >> > it wouldn't work, would it ? I mean, you still have to pass
>> through
>> >> >> > the
>> >> >> > "ugly" _db.get() thingy, right?
>> >> >> >
>> >> >> > how do you access and trigger the lazy bit within the class?
>> >> >> >
>> >> >> > On Thu, Aug 31, 2017 at 7:56 PM, Isiah Meadows
>> >> >> >
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> What about this (using the stage 3 class fields proposal)?
>> >> >> >>
>> >> >> >> ```js
>> >> >> >> declare function lazy(init: () => T): () => T;
>> >> >> >>
>> >> >> >> class WithLazyVals {
>> >> >> >> _db = lazy(() => new Promise(...));
>> >> >> >> }
>> >> >> >> ```
>> >> >> >> -
>> >> >> >>
>> >> >> >> Isiah Meadows
>> >> >> >> m...@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 1:34 PM, Andrea Giammarchi
>> >> >> >> wrote:
>> >> >> >> >> this proposal doesn't compose well with classes
>> >> >> >> >
>> >> >> >> > to expand a little, if you were proposing
>> >> >> >> >
>> >> >> >> > ```js
>> >> >> >> > class WithLazyVals {
>> >> >> >> > lazy _db() { return new Promise(...); }
>> >> >> >> > }
>> >> >> >> > ```
>> >> >> >> >
>> >> >> >> > I would've taken first flight to come over and hug you.
>> >> >> >> >
>> >> >> >> > Best Regards
>> >> >> >> >
>> >> >> >>
