Once upon a time we've discussed the "*thin arrow*" so that `{method: () ->
this.name, name: 'any'}` would've worked as expected.At that time it was considered "*an arrow too far*". Regards On Sun, Nov 18, 2018 at 3:30 PM T.J. Crowder < [email protected]> wrote: > On Fri, Nov 16, 2018 at 8:42 PM Sultan > <[email protected]> wrote: > > It has an added reach in usefulness when you consider nested > > classes: > > > > class A { > > foo() { > > return class B { > > bar() => { > > return this // refers to instance A > > } > > } > > } > > } > > > > This is not possible today without creating a self-like variable > > for bar to reference A's instance; Which is one of the points > > arrow functions addressed. > > It is, just not within the `class` construct: > > ```js > class A { > foo() { > class B { > } > B.prototype.bar = () => { > return this; // refers to instance A > }; > return B; > } > } > ``` > > I agree with Tab Atkins Jr.: In your nested classes example, I'd expect > `this` within `bar` to be the `B` instance, not the `A` instance. I think > the more natural definition of that syntax (if it were adopted) would be a > prototype function that is effectively auto-bound to the instance at > construction time, like this common pattern today: > > ```js > class B { > constructor() { > this.bar = this.bar.bind(this); > } > bar() { > return this; > } > } > ``` > > In fact I could see some benefit to that syntax, since people use class > fields for that use-case which can make mocking difficult. > > But I'm not keen on that syntax with the semantics you're proposing. > > -- T.J. Crowder > _______________________________________________ > 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
