> I don't see any point to having this on methods. On constructors, I
suppose it's a bit of convenience.

If it's supported on constructor functions, my reasoning was that it'd only
make sense for it to be supported on methods (which are also just
functions). Having this syntax available for functions allows really nice,
convenient data structures:
```js
function UserData(
  this.name,
  this.age,
  this.gender,
) {}

// probably more readable / better practice in usage, works just as well:
function UserData({
  name: this.name,
  age: this.age,
  gender: this.gender,
}) {}
```

While I'm on that subject, thoughts on this being equivalent to the above?
```js
function UserData({
  this.name,
  this.age,
  this.gender,
}) {}
```
I don't really like it because it looks _very_ similar to the approach with
named arguments; the braces are easy to miss, but it's still very succinct.

> How about `own` keyword? It might work with public and private fields,
and seems more elegant (because of destructuring we have a lot of symbols
in the paremeters declaration)

I'm against piling on too many unfamiliar language constructs. Even without
knowing ES2015+, the semantics of `this.*` assigns in a function
declaration are easily understood at a first glance, and meshes nicely with
everything else available in the language as is.

> More prior art, this time from C#, which shifts the burden from the
constructor to the call to it: You can set accessible properties in an
initializer after the call to the constructor:

Not for this either. This is easily done with `Object.assign` and similar.
```js
const obj = Object.assign(new Example(), { x: 1, y: 2 })
```

On Sat, Mar 18, 2017 at 3:13 PM T.J. Crowder <
tj.crowder at farsightsoftware.com> wrote:

> On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
> I'd think with the advent of private fields a much more
>
> common (and better) use case would not involve creating
>
> publicly visible properties - how might that work?
>
> Perhaps this:
> ```js
> class Foo {
>   constructor(#x, #y) { }
> }
> ```
>
>
> It seems strange to me to advertise your private properties like that, but
> of course, the source is right there anyway...
>
> Worth noting the TypeScript prior art:
>
> ```js
> // (TypeScript)
> class Example {
>     constructor(public x, public y) {
>     }
> }
> const e = new Example(1, 2);
> console.log(e.x); // 1
> console.log(e.y); // 2
> ```
>
> Note the access modifier on the parameters. (`private` works as well.)
>
> So quite similar to Jordan's `constructor(#x, #y)` for private data (if
> that horrible `#` does in fact happen in the private data proposal), and to
> "just nobody"'s `constructor(this.x, this.y)` for instance properties.
>
> I don't see any point to having this on methods. On constructors, I
> suppose it's a bit of convenience.
>
> More prior art, this time from C#, which shifts the burden from the
> constructor to the call to it: You can set accessible properties in an
> initializer after the call to the constructor:
>
> ```c#
> var obj = new Example() { x = 1, y = 2};
> Console.WriteLine(obj.x); // 1
> Console.WriteLine(obj.x); // 2
> ```
>
> -- T.J. Crowder
>
> On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband <ljharb at gmail.com> wrote:
>
> I'd think with the advent of private fields a much more common (and
> better) use case would not involve creating publicly visible properties -
> how might that work?
>
> Perhaps this:
> ```js
> class Foo {
>   constructor(#x, #y) { }
> }
> ```
>
> On Sat, Mar 18, 2017 at 11:00 AM, just nobody <kingdaro at gmail.com> wrote:
>
> Inherited methods would inherit the same behavior, since this is just
> syntactic sugar after all.
> ```js
> class Point {
>   setPosition(this.x, this.y) {}
>
>   // same as
>   // setPosition(x, y) { this.x = x; this.y = y }
> }
>
> class Rectangle extends Point {
>   setSize(this.width, this.height) {}
>
>   // same as
>   // setSize(width, height) { this.width = width; this.height = height }
> }
>
> let rect = new Rectangle()
> rect.setPosition(0, 0)
> rect.setSize(50, 50)
> rect // { x: 0, y: 0, width: 50, height: 50 }
> ```
>
> On Sat, Mar 18, 2017 at 7:12 AM Michael J. Ryan <tracker1 at gmail.com>
> wrote:
>
> Interesting concept... What about inheritance?
>
> --
> Michael J. Ryan - tracker1 at gmail.com - http://tracker1.info
>
> Please excuse grammar errors and typos, as this message was sent from my
> phone.
>
> On Mar 18, 2017 12:03 AM, "just nobody" <kingdaro at gmail.com> wrote:
>
> Would it be possible to have syntax like this? It's a feature supported by
> other JS variants in some way (CoffeeScript, TS) that feels missing from
> the spec. It's mainly useful as a convenient, terse way of setting
> properties of an object on initialization.
>
> ```js
> class Rectangle {
>   constructor (this.x, this.y, this.width, this.height) {}
>   setPosition(this.x, this.y) {}
>   setSize(this.width, this.height) {}
> }
>
> // equivalent to
> class Rectangle {
>   constructor (x, y, width, height) {
>     this.x = x
>     this.y = y
>     this.width = width
>     this.height = height
>   }
>
>   // ...
> }
>
> // for regular constructor functions as well
> function Rectangle (this.x, this.y, this.width, this.height) {}
> ```
>
> Deconstructing and argument defaults should all work similarly
> ```js
> function Point({ x: this.x, y: this.y }) {}
> function Point(this.x = 0, this.y = 0) {}
> function Point([this.x, this.y]) {}
> ```
>
>
> _______________________________________________
> 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/20170318/a701eddb/attachment-0001.html>

> I don't see any point to having this on methods. On constructors, I
> suppose it's a bit of convenience.

If it's supported on constructor functions, my reasoning was that it'd only
make sense for it to be supported on methods (which are also just
functions). Having this syntax available for functions allows really nice,
convenient data structures, and getter/setters as I've displayed in my
original post.
```js
function UserData(
  this.name,
  this.age,
  this.gender,
) {}

// probably more readable / better practice in usage, works just as well:
function UserData({
  name: this.name,
  age: this.age,
  gender: this.gender,
}) {}
```

While I'm on that subject, thoughts on this being equivalent to the above?
```js
function UserData({
  this.name,
  this.age,
  this.gender,
}) {}
```
I don't really like it because it looks _very_ similar to the approach with
named arguments; the braces are easy to miss, but it's still very succinct.

> How about `own` keyword? It might work with public and private fields,
> and seems more elegant (because of destructuring we have a lot of symbols
> in the paremeters declaration)

I'm against piling on too many unfamiliar language constructs. Even without
knowing ES2015+, the semantics of `this.*` assigns in a function
declaration are easily understood at a first glance, and meshes nicely with
everything else available in the language as is.

> More prior art, this time from C#, which shifts the burden from the
> constructor to the call to it: You can set accessible properties in an
> initializer after the call to the constructor:

Not for this either. This is easily done with `Object.assign` and similar.
```js
const obj = Object.assign(new Example(), { x: 1, y: 2 })
```

> I don't see any point to having this on methods. On constructors, I
> suppose it's a bit of convenience.

If it's supported on constructor functions, my reasoning was that it'd only
make sense for it to be supported on methods (which are also just
functions). Having this syntax available for functions allows really nice,
convenient data structures, and getter/setters as I've displayed in my
original post.
```js
function UserData(
  this.name,
  this.age,
  this.gender,
) {}

// probably more readable / better practice in usage, works just as well:
function UserData({
  name: this.name,
  age: this.age,
  gender: this.gender,
}) {}
```

While I'm on that subject, thoughts on this being equivalent to the above?
```js
function UserData({
  this.name,
  this.age,
  this.gender,
}) {}
```
I don't really like it because it looks _very_ similar to the approach with
named arguments; the braces are easy to miss, but it's still very succinct.

> How about `own` keyword? It might work with public and private fields,

and seems more elegant (because of destructuring we have a lot of symbols
in the paremeters declaration)

I'm against piling on too many unfamiliar language constructs. Even without
knowing ES2015+, the semantics of `this.*` assigns in a function
declaration are easily understood at a first glance, and meshes nicely with
everything else available in the language as is.

> More prior art, this time from C#, which shifts the burden from the
> constructor to the call to it: You can set accessible properties in an
> initializer after the call to the constructor:

Not for this either. This is easily done with `Object.assign` and similar.
```js
const obj = Object.assign(new Example(), { x: 1, y: 2 })
```

> I don't see any point to having this on methods. On constructors, I
> suppose it's a bit of convenience.

If it's supported on constructor functions, my reasoning was that it'd only
make sense for it to be supported on methods (which are also just
functions). Having this syntax available for functions allows really nice,
convenient data structures, and getter/setters as I've displayed in my
original post.
```js
function UserData(
  this.name,
  this.age,
  this.gender,
) {}

// probably more readable / better practice in usage, works just as well:
function UserData({
  name: this.name,
  age: this.age,
  gender: this.gender,
}) {}
```

While I'm on that subject, thoughts on this being equivalent to the above?
```js
function UserData({
  this.name,
  this.age,
  this.gender,
}) {}
```
I don't really like it because it looks _very_ similar to the approach with
named arguments; the braces are easy to miss, but it's still very succinct.

> How about `own` keyword? It might work with public and private fields,

and seems more elegant (because of destructuring we have a lot of symbols
in the paremeters declaration)

I'm against piling on too many unfamiliar language constructs. Even without
knowing ES2015+, the semantics of `this.*` assigns in a function
declaration are easily understood at a first glance, and meshes nicely with
everything else available in the language as is.

> More prior art, this time from C#, which shifts the burden from the

constructor to the call to it: You can set accessible properties in an
initializer after the call to the constructor:

Not for this either. This is easily done with `Object.assign` and similar.
```js
const obj = Object.assign(new Example(), { x: 1, y: 2 })
```