Field initializers

Jordan Harband ljharb at gmail.com
Sat Mar 18 22:53:59 UTC 2017


I'm not saying we couldn't do both; I"m saying we wouldn't want to make
"public" easy unless "private" was equally easy, because private is a
better default.

On Sat, Mar 18, 2017 at 12:32 PM, just nobody <kingdaro at gmail.com> wrote:

> > 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/e993b968/attachment-0001.html>


More information about the es-discuss mailing list