C# has a similar syntax for shorthand expression bodies
(https://github.com/dotnet/roslyn/wiki/New-Language-Features-in-C%23-6#expression-bodies-on-method-like-members):
```cs
class Point {
private int x;
private int y;
…
// expression bodied getters (read-only)
public int X => x;
public int Y => y;
// expression bodied method
public Point Move(int dx, int dy) => new Point(x + dx, y + dy);
}
```
From: es-discuss <[email protected]> On Behalf Of T.J. Crowder
Sent: Sunday, November 18, 2018 6:31 AM
To: Sultan <[email protected]>
Cc: [email protected]
Subject: Re: Arrow methods
On Fri, Nov 16, 2018 at 8:42 PM Sultan
<[email protected]<mailto:[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
