Re: Re: Proposal for faster this assignments in constructor functions
I can see that, although I'm struggling to come to that conclusion if I saw
that block of code fresh. I don't think it would be immediately clear,
though. In your interpretation of "this has 5 arguments", what would you
expect them to be? `constructor(x, y, a, b, c)`? Just prepend them?
I'm trying to work with the idea of the existing constructor function and a
possible shorthand. Another problem with almost any suggestion is how it
may interact with destructuring and expectations (with any additions of
"bind these").
I am highly suspect that any solution that is both ergonomic and concise
could pass.
What about making an explicit `constructor` function invalid in the case of
the shorthand syntax?
```js
class Point(x, y) {
...
}
// As shorthand for:
class Point {
constructor(x, y){
this.x = x;
this.y = y;
}
}
```
If this kind of syntax can't fly, that's fine, but I feel there isn't going
to be an ergonomic way to have a simple way to bind constructor arguments.
Although that makes things like super calls potentially awkward, we can
also assume that if you extend a class that it calls super in the generated
constructor. I'm not offended by a short hand as my last post, as the
transition is quite natural if you need a more complex use case:
```js
class Point(x, y) {
toString() { ... }
}
// Oh no, now I have complex logic!
class Point {
constructor(x, y) {
Object.assign(this, {x, y});
...
}
toString() { ... }
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal for faster this assignments in constructor functions
Your imagined syntax would suggest to me that the constructor had 5
arguments, not 3 - it seems strange to me to have "x" and "a" be implicitly
two ways to refer to the same thing.
On Thu, Dec 6, 2018 at 8:56 AM dante federici
wrote:
> Any reason we can't consider a scala-like constructor?
>
> ```js
> class Point(x, y) {
> toString() {
> return `(${this.x},${this.y})`
> }
> }
>
> console.log(`??? ${new Point(1, 2)}`); // ??? 1,2
>
>
> Doesn't conflict with existing syntax, it's clear, and you can still
> shorthand most data-classes or structs to just:
> ```
> class MyData(some, props, here) {}
> ```
>
> I imagine this as the syntax:
> ```
> class Point(x, y) { // implicits x, y as first two args of constru
> constructor(a, b, c) {
> this.z = a + b + c;
> console.log(this.x, this.y, this.c); // values of: a, b, c
> console.log(this.x === a, this.y === b); // true, true
> }
> }
> ```
>
> And de-sugared:
> ```
> class Point {
> constructor(a, b, c) {
> this.x = a;
> this.y = b;
> // rest of body
> this.z = a + b + c;
> }
> }
> ```
>
> ___
> 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: Re: Proposal for faster this assignments in constructor functions
Any reason we can't consider a scala-like constructor?
```js
class Point(x, y) {
toString() {
return `(${this.x},${this.y})`
}
}
console.log(`??? ${new Point(1, 2)}`); // ??? 1,2
Doesn't conflict with existing syntax, it's clear, and you can still
shorthand most data-classes or structs to just:
```
class MyData(some, props, here) {}
```
I imagine this as the syntax:
```
class Point(x, y) { // implicits x, y as first two args of constru
constructor(a, b, c) {
this.z = a + b + c;
console.log(this.x, this.y, this.c); // values of: a, b, c
console.log(this.x === a, this.y === b); // true, true
}
}
```
And de-sugared:
```
class Point {
constructor(a, b, c) {
this.x = a;
this.y = b;
// rest of body
this.z = a + b + c;
}
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
``this = { ...this, par1, par2, par3 }```
Oh, wait, I'm going to point out the problem with what I wrote before
anyone else does: this will lose any non-enumerable properties on `this`,
which in a class instance is kind of a big no-no. `Object.assign` is better
here.
On Sat, 1 Dec 2018 at 20:08 Michael Luder-Rosefield
wrote:
> > ```js
> this.{} = {par1, par2, par3};
> ```
>
> Of course, that could be expressed as ```this = { ...this, par1, par2,
> par3 }```, but that's still a bit verbose.
>
> I already know this is going to get dismissed for changing the way the `+`
> operator works, but it strikes me that a better way of expressing that
> might be ```this += { par1, par2, par3 }```.
>
> That naturally leads to having ```obj1 + obj2 === Object.assign(obj1,
> obj2)``` and ```arr1 + arr2 === (arr1 = [ ...arr1, ...arr2 ])```, which
> would be good except for the whole breaking-change thing.
>
> On Fri, 30 Nov 2018 at 22:52 Simo Costa wrote:
>
>> Thank you T.J. Crowder for giving me your opinion on this proposal.
>> I didn't know about the Bob Myers' for pick notation and it isn't bad.
>>
>> I still prefer something like that:
>> ```js
>> constructor(this.{par1, par2, par3}) {
>> }
>> ```
>>
>> but this doesn't sound bad to me:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{} = {par1, par2, par3};
>> }
>> ```
>>
>> There is still a repetition, but it is a a step forward.
>>
>> Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
>> tj.crow...@farsightsoftware.com> ha scritto:
>>
>>> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
>>> wrote:
>>> >
>>> > So my proposal is to avoid those repetitions...
>>>
>>> I'm a bit surprised to find that no one's mentioned Bob Myers'
>>> [proposal][1] for pick notation yet, which would readily address this
>>> requirement *and* various other requirements beyond initializing
>>> newly-constructed objects.
>>>
>>> Using Bob's current draft syntax, Simo's example would be:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{par1, par2, par3} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> or if the constructor accepts an object:
>>>
>>> ```js
>>> constructor(options) {
>>> this.{par1, par2, par3} = options;
>>> }
>>> ```
>>>
>>> But I think we can go further if we tweak the syntax a bit. Perhaps:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> ...where the property names are inferred from the properties on the
>>> right-hand side. That would be functionally equivalent to:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> Object.assign(this, {par1, par2, par3});
>>> }
>>> ```
>>>
>>> ...but since the syntax is clear about the intent, when an object
>>> initializer (rather than just object reference) is used on the right-hand
>>> side it's an optimization target if a constructor is "hot" enough to
>>> justify it (e.g., an engine could optimize it into individual assignments).
>>>
>>> For me, that would be a great, clear, concise feature, and hits the
>>> other use cases Bob mentions in his proposal. I like that I'm still in
>>> control of what parameters get assigned as properties (which I think has
>>> been true of all of the suggestsions in this thread).
>>>
>>> -- T.J. Crowder
>>>
>>> [1]: https://github.com/rtm/js-pick-notation
>>>
>> ___
>> 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: Proposal for faster this assignments in constructor functions
@Michael Luder-Rosefield
```js
this += { par1, par2, par3 }
```
I do love it!!!
Il giorno sab 1 dic 2018 alle ore 12:08 Michael Luder-Rosefield <
rosyatran...@gmail.com> ha scritto:
> > ```js
> this.{} = {par1, par2, par3};
> ```
>
> Of course, that could be expressed as ```this = { ...this, par1, par2,
> par3 }```, but that's still a bit verbose.
>
> I already know this is going to get dismissed for changing the way the `+`
> operator works, but it strikes me that a better way of expressing that
> might be ```this += { par1, par2, par3 }```.
>
> That naturally leads to having ```obj1 + obj2 === Object.assign(obj1,
> obj2)``` and ```arr1 + arr2 === (arr1 = [ ...arr1, ...arr2 ])```, which
> would be good except for the whole breaking-change thing.
>
> On Fri, 30 Nov 2018 at 22:52 Simo Costa wrote:
>
>> Thank you T.J. Crowder for giving me your opinion on this proposal.
>> I didn't know about the Bob Myers' for pick notation and it isn't bad.
>>
>> I still prefer something like that:
>> ```js
>> constructor(this.{par1, par2, par3}) {
>> }
>> ```
>>
>> but this doesn't sound bad to me:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{} = {par1, par2, par3};
>> }
>> ```
>>
>> There is still a repetition, but it is a a step forward.
>>
>> Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
>> tj.crow...@farsightsoftware.com> ha scritto:
>>
>>> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
>>> wrote:
>>> >
>>> > So my proposal is to avoid those repetitions...
>>>
>>> I'm a bit surprised to find that no one's mentioned Bob Myers'
>>> [proposal][1] for pick notation yet, which would readily address this
>>> requirement *and* various other requirements beyond initializing
>>> newly-constructed objects.
>>>
>>> Using Bob's current draft syntax, Simo's example would be:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{par1, par2, par3} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> or if the constructor accepts an object:
>>>
>>> ```js
>>> constructor(options) {
>>> this.{par1, par2, par3} = options;
>>> }
>>> ```
>>>
>>> But I think we can go further if we tweak the syntax a bit. Perhaps:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> this.{} = {par1, par2, par3};
>>> }
>>> ```
>>>
>>> ...where the property names are inferred from the properties on the
>>> right-hand side. That would be functionally equivalent to:
>>>
>>> ```js
>>> constructor(par1, par2, par3) {
>>> Object.assign(this, {par1, par2, par3});
>>> }
>>> ```
>>>
>>> ...but since the syntax is clear about the intent, when an object
>>> initializer (rather than just object reference) is used on the right-hand
>>> side it's an optimization target if a constructor is "hot" enough to
>>> justify it (e.g., an engine could optimize it into individual assignments).
>>>
>>> For me, that would be a great, clear, concise feature, and hits the
>>> other use cases Bob mentions in his proposal. I like that I'm still in
>>> control of what parameters get assigned as properties (which I think has
>>> been true of all of the suggestsions in this thread).
>>>
>>> -- T.J. Crowder
>>>
>>> [1]: https://github.com/rtm/js-pick-notation
>>>
>> ___
>> 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: Proposal for faster this assignments in constructor functions
@T.J. Crowder
No problems for the error :P.
Anyway I know Typescript's approach but I prefer something like:
```js
class Example {
constructor(this.{foo, #bar}) {
}
showFoo() {
console.log(e1.foo);
}
showBar() {
console.log(e1.#bar);
}
}
const e1 = new Example("answer", 42);
e1.showFoo(); // "answer"
e1.showBar(); // 42
```
To both declare, if not already declared, and initialize public and
private properties.
Il giorno sab 1 dic 2018 alle ore 11:13 T.J. Crowder <
tj.crow...@farsightsoftware.com> ha scritto:
> On Fri, Nov 30, 2018 at 5:49 PM T.J. Crowder
> wrote:
>
> > which is
> >
> > ```js
> > class Example {
> > ...
> > }
>
> Apologies, that "which is" at the end of my previous message should have
> been:
>
> ```js
> class Example {
> second;
> #third;
> fifth;
> constructor(first, second, third, fourth, fifth) {
> this.second = second;
> this.#third = third;
> this.fifth = fifth;
> // presumably code here uses `first` and `fourth`
> }
> }
> ```
>
> Editing error. :-)
>
> -- T.J. Crowder
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
> ```js
this.{} = {par1, par2, par3};
```
Of course, that could be expressed as ```this = { ...this, par1, par2, par3
}```, but that's still a bit verbose.
I already know this is going to get dismissed for changing the way the `+`
operator works, but it strikes me that a better way of expressing that
might be ```this += { par1, par2, par3 }```.
That naturally leads to having ```obj1 + obj2 === Object.assign(obj1,
obj2)``` and ```arr1 + arr2 === (arr1 = [ ...arr1, ...arr2 ])```, which
would be good except for the whole breaking-change thing.
On Fri, 30 Nov 2018 at 22:52 Simo Costa wrote:
> Thank you T.J. Crowder for giving me your opinion on this proposal.
> I didn't know about the Bob Myers' for pick notation and it isn't bad.
>
> I still prefer something like that:
> ```js
> constructor(this.{par1, par2, par3}) {
> }
> ```
>
> but this doesn't sound bad to me:
>
> ```js
> constructor(par1, par2, par3) {
> this.{} = {par1, par2, par3};
> }
> ```
>
> There is still a repetition, but it is a a step forward.
>
> Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
> tj.crow...@farsightsoftware.com> ha scritto:
>
>> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
>> wrote:
>> >
>> > So my proposal is to avoid those repetitions...
>>
>> I'm a bit surprised to find that no one's mentioned Bob Myers'
>> [proposal][1] for pick notation yet, which would readily address this
>> requirement *and* various other requirements beyond initializing
>> newly-constructed objects.
>>
>> Using Bob's current draft syntax, Simo's example would be:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{par1, par2, par3} = {par1, par2, par3};
>> }
>> ```
>>
>> or if the constructor accepts an object:
>>
>> ```js
>> constructor(options) {
>> this.{par1, par2, par3} = options;
>> }
>> ```
>>
>> But I think we can go further if we tweak the syntax a bit. Perhaps:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> this.{} = {par1, par2, par3};
>> }
>> ```
>>
>> ...where the property names are inferred from the properties on the
>> right-hand side. That would be functionally equivalent to:
>>
>> ```js
>> constructor(par1, par2, par3) {
>> Object.assign(this, {par1, par2, par3});
>> }
>> ```
>>
>> ...but since the syntax is clear about the intent, when an object
>> initializer (rather than just object reference) is used on the right-hand
>> side it's an optimization target if a constructor is "hot" enough to
>> justify it (e.g., an engine could optimize it into individual assignments).
>>
>> For me, that would be a great, clear, concise feature, and hits the other
>> use cases Bob mentions in his proposal. I like that I'm still in control of
>> what parameters get assigned as properties (which I think has been true of
>> all of the suggestsions in this thread).
>>
>> -- T.J. Crowder
>>
>> [1]: https://github.com/rtm/js-pick-notation
>>
> ___
> 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: Proposal for faster this assignments in constructor functions
On Fri, Nov 30, 2018 at 5:49 PM T.J. Crowder
wrote:
> which is
>
> ```js
> class Example {
> ...
> }
Apologies, that "which is" at the end of my previous message should have
been:
```js
class Example {
second;
#third;
fifth;
constructor(first, second, third, fourth, fifth) {
this.second = second;
this.#third = third;
this.fifth = fifth;
// presumably code here uses `first` and `fourth`
}
}
```
Editing error. :-)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
On Fri, Nov 30, 2018 at 1:52 PM Simo Costa
wrote:
>
> There is still a repetition, but it is a a step forward.
Yeah. :-| For me, for public properties, it's good enough, but I hear you.
It's a lot of repetition for private fields, though.
Just FWIW by way of prior art, it's probably worth noting TypeScript's
approach, though I'm fairly certain it won't be adopted by JavaScript:
```typescript
class Example {
constructor(
public foo: string,
private bar: number
) {
}
showFoo() {
console.log(e1.foo);
}
showBar() {
console.log(e1.bar);
}
}
const e1 = new Example("answer", 42);
e1.showFoo(); // "answer"
e1.showBar(); // 42
```
The `public` and `private` in the parameter list both declare them as
members of the type and auto-initialize them from the parameters. (That
`private` is TypeScript's version of private, not JavaScript's -- the
member is not part of the type's public interface, just its private one, so
the TypeScript compiler can error on inappropriate use, but the transpiled
JavaScript has them as normal properties.)
The equivalent (but with real private fields) with the [class fields
proposal][1] would be:
```typescript
class Example {
foo;
#bar;
constructor(foo, bar) {
this.foo = foo;
this.#bar = bar;
}
showFoo() {
console.log(e1.foo);
}
showBar() {
console.log(e1.#bar);
}
}
const e1 = new Example("answer", 42);
e1.showFoo(); // "answer"
e1.showBar(); // 42
```
So, that's typing `foo` and `bar` four types rather than once (in
TypeScript). (Okay, we could have skipped the `foo` declaration and only
typed `foo` three times; but you have to declare private fields, so it's
four for `#bar`/`bar`.)
Continuing the train of thought and taking inspiration from TypeScript
**and** Bob's proposal, this could be a follow-on if Bob's progresses
(which I'd very much like to see):
```js
class Example {
constructor(this.{foo, #bar}) {
}
showFoo() {
console.log(e1.foo);
}
showBar() {
console.log(e1.#bar);
}
}
const e1 = new Example("answer", 42);
e1.showFoo(); // "answer"
e1.showBar(); // 42
```
That construct would both declare (if not already declared) and initialize.
You could repeat it as necessary. For instance, if your constructor
*really* needs a non-property as its first and fourth parameters and
properties/fields as its second, third, and fifth:
```js
class Example {
constructor(first, this.{second, #third}, fourth, this.{fifth}) {
// presumably code here uses `first` and `fourth`
}
}
```
which is
```js
class Example {
second;
#third;
fifth;
constructor(first, this.{second, #third}, fourth, this.{fifth}) {
this.second = second;
this.#third = third;
this.fifth = fifth;
// presumably code here uses `first` and `fourth`
}
}
```
Not a parameter list I'd design without a really, really good reason, but...
Food for thought.
-- T.J. Crowder
[1]: https://github.com/tc39/proposal-class-fields/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
Thank you T.J. Crowder for giving me your opinion on this proposal.
I didn't know about the Bob Myers' for pick notation and it isn't bad.
I still prefer something like that:
```js
constructor(this.{par1, par2, par3}) {
}
```
but this doesn't sound bad to me:
```js
constructor(par1, par2, par3) {
this.{} = {par1, par2, par3};
}
```
There is still a repetition, but it is a a step forward.
Il giorno gio 29 nov 2018 alle ore 12:28 T.J. Crowder <
tj.crow...@farsightsoftware.com> ha scritto:
> On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
> wrote:
> >
> > So my proposal is to avoid those repetitions...
>
> I'm a bit surprised to find that no one's mentioned Bob Myers'
> [proposal][1] for pick notation yet, which would readily address this
> requirement *and* various other requirements beyond initializing
> newly-constructed objects.
>
> Using Bob's current draft syntax, Simo's example would be:
>
> ```js
> constructor(par1, par2, par3) {
> this.{par1, par2, par3} = {par1, par2, par3};
> }
> ```
>
> or if the constructor accepts an object:
>
> ```js
> constructor(options) {
> this.{par1, par2, par3} = options;
> }
> ```
>
> But I think we can go further if we tweak the syntax a bit. Perhaps:
>
> ```js
> constructor(par1, par2, par3) {
> this.{} = {par1, par2, par3};
> }
> ```
>
> ...where the property names are inferred from the properties on the
> right-hand side. That would be functionally equivalent to:
>
> ```js
> constructor(par1, par2, par3) {
> Object.assign(this, {par1, par2, par3});
> }
> ```
>
> ...but since the syntax is clear about the intent, when an object
> initializer (rather than just object reference) is used on the right-hand
> side it's an optimization target if a constructor is "hot" enough to
> justify it (e.g., an engine could optimize it into individual assignments).
>
> For me, that would be a great, clear, concise feature, and hits the other
> use cases Bob mentions in his proposal. I like that I'm still in control of
> what parameters get assigned as properties (which I think has been true of
> all of the suggestsions in this thread).
>
> -- T.J. Crowder
>
> [1]: https://github.com/rtm/js-pick-notation
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
On Wed, Nov 28, 2018 at 6:33 PM Simo Costa
wrote:
>
> So my proposal is to avoid those repetitions...
I'm a bit surprised to find that no one's mentioned Bob Myers'
[proposal][1] for pick notation yet, which would readily address this
requirement *and* various other requirements beyond initializing
newly-constructed objects.
Using Bob's current draft syntax, Simo's example would be:
```js
constructor(par1, par2, par3) {
this.{par1, par2, par3} = {par1, par2, par3};
}
```
or if the constructor accepts an object:
```js
constructor(options) {
this.{par1, par2, par3} = options;
}
```
But I think we can go further if we tweak the syntax a bit. Perhaps:
```js
constructor(par1, par2, par3) {
this.{} = {par1, par2, par3};
}
```
...where the property names are inferred from the properties on the
right-hand side. That would be functionally equivalent to:
```js
constructor(par1, par2, par3) {
Object.assign(this, {par1, par2, par3});
}
```
...but since the syntax is clear about the intent, when an object
initializer (rather than just object reference) is used on the right-hand
side it's an optimization target if a constructor is "hot" enough to
justify it (e.g., an engine could optimize it into individual assignments).
For me, that would be a great, clear, concise feature, and hits the other
use cases Bob mentions in his proposal. I like that I'm still in control of
what parameters get assigned as properties (which I think has been true of
all of the suggestsions in this thread).
-- T.J. Crowder
[1]: https://github.com/rtm/js-pick-notation
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
going faster
When or more than one parameters should be inserted into an object we could
do like that:
f(.{par1, par2, parN}) {}
equivalent to:
f(this.{par1, par2, parN}) {}
that is equivaent to:
f(.par1, .par2, .parN) {}
and:
f(this.par1, this.par2, this.parN) {}
SO we could write that:
f(obj.par1, obj.par2, obj2.parN) {}
in this way:
f(obj.{par1, par2}, obj2.parN) {}
Il giorno gio 29 nov 2018 alle ore 09:42 Simo Costa
ha scritto:
> going faster
>
> When or more than one parameters should be inserted into an object we
> could do like that:
>
> f(.{par1, par2, parN}) {}
>
> equivalent to:
>
> f(this.{par1, par2, parN}) {}
>
> that is equivaent to:
>
> f(.par1, .par2, .parN) {}
>
> and:
>
> f(this.par1, this.par2, this.parN) {}
>
>
> SO we could write that:
>
> f(obj.par1, obj.par2, obj2.parN) {}
>
> in this way:
>
> f(obj.{par1, par2}, obj2.parN) {}
>
>
> Il giorno gio 29 nov 2018 alle ore 09:00 Simo Costa <
> andrysimo1...@gmail.com> ha scritto:
>
>> Thanks for partecipating to this discussion and for your opinions on my
>> proposal. I cannot reply to each one of you now, but I'd like to receive
>> feedback also on the Further Ideas section. Maybeyou'll find something
>> interesting.
>>
>> In JS there is no way (please correct me if you find the way) to gather
>> all arguments directly in a object (without passing directly an object obv)
>> like you can easily do with an array.
>>
>> So, to mantain this way to pass the arguments:
>>
>> ```
>>
>> f(arg1, arg2, arg3);
>>
>> ```
>>
>> you could do like that to store them into an array:
>>
>> ```
>>
>> function f(...args){
>>
>> /* code */
>>
>> }
>>
>> ```
>>
>> but something like that won't work if u want gather them into a obj:
>>
>> ``
>>
>> function f({...obj}){
>>
>> /* code */
>>
>> }
>>
>> ```
>>
>> My proposal could solve this problem.
>>
>>
>> P.S.
>>
>> Though you pass an object created on the fly (and this is wath I'd like
>> to avoid):
>>
>> ```
>>
>> f( { arg1, arg2, arg3 } );
>>
>> ```
>> to make that work:
>>
>> ``
>>
>> function f({...obj}){
>>
>> /* code */
>>
>> }
>>
>> ```
>> you cannot do something like that directly:
>>
>> ```
>>
>> function a ( { arg1: obj.arg1, arg2: obj2.arg2, arg3: obj2.arg3 }) {}
>>
>> ```
>> My proposal theoretically could solve this "problem" too.
>>
>> Il giorno gio 29 nov 2018 alle ore 00:59 Ron Buckton <
>> ron.buck...@microsoft.com> ha scritto:
>>
>>> Dart has something like this:
>>> https://www.dartlang.org/guides/language/language-tour#constructors
>>>
>>>
>>>
>>> ```dart
>>>
>>> class Point {
>>>
>>> num x, y;
>>>
>>>
>>>
>>> // Syntactic sugar for setting x and y
>>>
>>> // before the constructor body runs.
>>>
>>> Point(this.x, this.y);
>>>
>>> }
>>>
>>> ```
>>>
>>>
>>>
>>> I could see a form of BindingElement (et al) that allows `this` or
>>> `this` `.` BindingIdentifier:
>>>
>>>
>>>
>>> ```js
>>>
>>> class Point {
>>>
>>> constructor(this.x, this.y) {}
>>>
>>> }
>>>
>>> new Point(10, 20).x; // 10
>>>
>>>
>>>
>>> class Foo {
>>>
>>> constructor(this.x, { y: this.z, …this }) {}
>>>
>>> }
>>>
>>> const f = new Foo(1, { y: 2, w: 3 });
>>>
>>> f.x; // 1
>>>
>>> f.z; // 2
>>>
>>> f.w; // 3
>>>
>>> ```
>>>
>>>
>>>
>>> TypeScript has something similar for constructors in the form of
>>> “parameter property assignments”, but they are triggered by the presence of
>>> an modifier (i.e. `public`, `private`, `protected`, `readonly`).
>>>
>>>
>>>
>>> Ron
>>>
>>>
>>>
>>> *From:* es-discuss * On Behalf Of *Claude
>>> Pache
>>> *Sent:* Wednesday, November 28, 2018 11:46 AM
>>> *To:* Simo Costa
>>> *Cc:* es-discuss@mozilla.org
>>> *Subject:* Re: Proposal for faster this assignments in constructor
>>> functions
>>>
>>>
>>>
>>>
>>>
>>> Le 28 nov. 2018 à 19:32, Simo Costa a écrit :
>>>
>>>
>>>
>>> In costructor functions and in the constructor() method in ES6 classes
>>> is easily to fall in the following pattern:
>>>
>>> F(par1, par2, ..., parN) {
>>>
>>> this.par1 = par1;
>>>
>>> this.par2 = par2;
>>>
>>> ...
>>>
>>> this.parN = parN;
>>>
>>> }
>>>
>>>
>>>
>>> So my proposal is to avoid those repetitions by prefixing a dot *.* to
>>> each parameter:
>>>
>>> F(.par1, .par2, ..., .parN) {}
>>>
>>> Simple but quite useful. More info here:
>>> https://github.com/jfet97/proposal-fast-this-assignments
>>>
>>>
>>>
>>>
>>>
>>>
>>> Simple, but a brand new and nonobvious syntax, for a relatively limited
>>> use case.
>>>
>>>
>>>
>>> Also, just one dot is too inconspicuous. At the very least, I’d prefer:
>>>
>>>
>>>
>>> ```js
>>>
>>> function F(this.par1, this.par2, this.par3) { }
>>>
>>> ```
>>>
>>>
>>>
>>> whose meaning is somewhat more intuitive.
>>>
>>>
>>>
>>>
>>>
>>> Also
Re: Proposal for faster this assignments in constructor functions
Thanks for partecipating to this discussion and for your opinions on my
proposal. I cannot reply to each one of you now, but I'd like to receive
feedback also on the Further Ideas section. Maybeyou'll find something
interesting.
In JS there is no way (please correct me if you find the way) to gather all
arguments directly in a object (without passing directly an object obv)
like you can easily do with an array.
So, to mantain this way to pass the arguments:
```
f(arg1, arg2, arg3);
```
you could do like that to store them into an array:
```
function f(...args){
/* code */
}
```
but something like that won't work if u want gather them into a obj:
``
function f({...obj}){
/* code */
}
```
My proposal could solve this problem.
P.S.
Though you pass an object created on the fly (and this is wath I'd like to
avoid):
```
f( { arg1, arg2, arg3 } );
```
to make that work:
``
function f({...obj}){
/* code */
}
```
you cannot do something like that directly:
```
function a ( { arg1: obj.arg1, arg2: obj2.arg2, arg3: obj2.arg3 }) {}
```
My proposal theoretically could solve this "problem" too.
Il giorno gio 29 nov 2018 alle ore 00:59 Ron Buckton <
ron.buck...@microsoft.com> ha scritto:
> Dart has something like this:
> https://www.dartlang.org/guides/language/language-tour#constructors
>
>
>
> ```dart
>
> class Point {
>
> num x, y;
>
>
>
> // Syntactic sugar for setting x and y
>
> // before the constructor body runs.
>
> Point(this.x, this.y);
>
> }
>
> ```
>
>
>
> I could see a form of BindingElement (et al) that allows `this` or `this`
> `.` BindingIdentifier:
>
>
>
> ```js
>
> class Point {
>
> constructor(this.x, this.y) {}
>
> }
>
> new Point(10, 20).x; // 10
>
>
>
> class Foo {
>
> constructor(this.x, { y: this.z, …this }) {}
>
> }
>
> const f = new Foo(1, { y: 2, w: 3 });
>
> f.x; // 1
>
> f.z; // 2
>
> f.w; // 3
>
> ```
>
>
>
> TypeScript has something similar for constructors in the form of
> “parameter property assignments”, but they are triggered by the presence of
> an modifier (i.e. `public`, `private`, `protected`, `readonly`).
>
>
>
> Ron
>
>
>
> *From:* es-discuss * On Behalf Of *Claude
> Pache
> *Sent:* Wednesday, November 28, 2018 11:46 AM
> *To:* Simo Costa
> *Cc:* es-discuss@mozilla.org
> *Subject:* Re: Proposal for faster this assignments in constructor
> functions
>
>
>
>
>
> Le 28 nov. 2018 à 19:32, Simo Costa a écrit :
>
>
>
> In costructor functions and in the constructor() method in ES6 classes is
> easily to fall in the following pattern:
>
> F(par1, par2, ..., parN) {
>
> this.par1 = par1;
>
> this.par2 = par2;
>
> ...
>
> this.parN = parN;
>
> }
>
>
>
> So my proposal is to avoid those repetitions by prefixing a dot *.* to
> each parameter:
>
> F(.par1, .par2, ..., .parN) {}
>
> Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
>
>
>
>
>
>
> Simple, but a brand new and nonobvious syntax, for a relatively limited
> use case.
>
>
>
> Also, just one dot is too inconspicuous. At the very least, I’d prefer:
>
>
>
> ```js
>
> function F(this.par1, this.par2, this.par3) { }
>
> ```
>
>
>
> whose meaning is somewhat more intuitive.
>
>
>
>
>
> Also noteworthy: in many cases, you can already reduce repetition with the
> combination of `Object.assign`, improved syntax literal, and imagination;
> see:
>
>
>
> http://2ality.com/2014/12/es6-oop.html#use-cases-for-objectassign
>
>
>
>
>
>
> —Claude
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
just to clarify, my previous -1 was to Augusto's decorator-suggestion.
but I'm against the the main proposal as well due extra cognitive-load of
decoding the "." prefix when debugging code not written by me. I already
have readability problems with {...} brackets due to destructuring,
es-classes, and fat-arrows.
-kai
On Thu, Nov 29, 2018, 11:00 kai zhu wrote:
> -1
>
> this makes the common javascript-painpoint of pinpointing bugs in
> UX-workflows even worse.
>
> you're getting invalid visualization or timeouts from the web-UI during
> integration/qa. maybe it's from a bug in following low-level code? if so,
> was bug from a) constructor, b) foo, or c) @field?
>
> > class Foo {
> > constructor(@field foo) {
> > }
> > }
> > var bar = new Foo(foo);
>
> this is also why i'm against decorators in general. i've used them in
> python, and beyond toy-cases, it quickly becomes very confusing whether I
> should put my business-logic in the decorator or the function ... and pity
> to any poor-soul debugging my code trying to figure it out, or worse ends
> up having to refactor the decorator (without breaking any of the functions
> it touches).
>
> -kai
>
>
>
> On Thu, Nov 29, 2018, 07:33 Isiah Meadows wrote:
>
>> Just dropping in real quick to correct a couple things.
>>
>> First, `arguments` itself is *not* deprecated in strict mode. Things
>> like `arguments.caller` are deprecated and throw a `TypeError` when
>> the corresponding function is in strict mode.
>>
>> Second, some of you all were looking to use `Object.assign` to help
>> explain. You'd need to do this for it to be correct:
>>
>> ```js
>> class C {
>> constructor(a, b, ..., y, z) {
>> Object.assign(this, {a, b, ..., y, z})
>> }
>> }
>> ```
>>
>> (Not TC39, just I felt the need to correct people here.)
>>
>> -
>>
>> Isiah Meadows
>> cont...@isiahmeadows.com
>> www.isiahmeadows.com
>> On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura
>> wrote:
>> >
>> > I forgot the links in my last email, here they are:
>> > [1] https://github.com/tc39/proposal-decorators
>> > [2]
>> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
>> > Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
>> > escreveu:
>> > >
>> > > In the ~maybe long~ future , after the current decorators proposal
>> [1], we can start thinking about a Method Parameter Decorator (already
>> proposed [2]), we could do something like:
>> > >
>> > > ``` js
>> > > class Foo {
>> > > constructor(@field foo) {
>> > > }
>> > > }
>> > > ```
>> > >
>> > > In my opinion, it would be a much more powerful approach
>> > > Em qua, 28 de nov de 2018 às 16:33, Simo Costa <
>> andrysimo1...@gmail.com> escreveu:
>> > > >
>> > > > In costructor functions and in the constructor() method in ES6
>> classes is easily to fall in the following pattern:
>> > > >
>> > > > F(par1, par2, ..., parN) {
>> > > > this.par1 = par1;
>> > > > this.par2 = par2;
>> > > > ...
>> > > > this.parN = parN;
>> > > > }
>> > > >
>> > > >
>> > > > So my proposal is to avoid those repetitions by prefixing a dot .
>> to each parameter:
>> > > >
>> > > > F(.par1, .par2, ..., .parN) {}
>> > > >
>> > > > Simple but quite useful. More info here:
>> https://github.com/jfet97/proposal-fast-this-assignments
>> > > >
>> > > >
>> > > >
>> > > > ___
>> > > > es-discuss mailing list
>> > > > es-discuss@mozilla.org
>> > > > https://mail.mozilla.org/listinfo/es-discuss
>> > >
>> > >
>> > >
>> > > --
>> > > Atenciosamente,
>> > >
>> > > Augusto Borges de Moura
>> >
>> >
>> >
>> > --
>> > Atenciosamente,
>> >
>> > Augusto Borges de Moura
>> > ___
>> > 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: Proposal for faster this assignments in constructor functions
-1
this makes the common javascript-painpoint of pinpointing bugs in
UX-workflows even worse.
you're getting invalid visualization or timeouts from the web-UI during
integration/qa. maybe it's from a bug in following low-level code? if so,
was bug from a) constructor, b) foo, or c) @field?
> class Foo {
> constructor(@field foo) {
> }
> }
> var bar = new Foo(foo);
this is also why i'm against decorators in general. i've used them in
python, and beyond toy-cases, it quickly becomes very confusing whether I
should put my business-logic in the decorator or the function ... and pity
to any poor-soul debugging my code trying to figure it out, or worse ends
up having to refactor the decorator (without breaking any of the functions
it touches).
-kai
On Thu, Nov 29, 2018, 07:33 Isiah Meadows wrote:
> Just dropping in real quick to correct a couple things.
>
> First, `arguments` itself is *not* deprecated in strict mode. Things
> like `arguments.caller` are deprecated and throw a `TypeError` when
> the corresponding function is in strict mode.
>
> Second, some of you all were looking to use `Object.assign` to help
> explain. You'd need to do this for it to be correct:
>
> ```js
> class C {
> constructor(a, b, ..., y, z) {
> Object.assign(this, {a, b, ..., y, z})
> }
> }
> ```
>
> (Not TC39, just I felt the need to correct people here.)
>
> -
>
> Isiah Meadows
> cont...@isiahmeadows.com
> www.isiahmeadows.com
> On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura
> wrote:
> >
> > I forgot the links in my last email, here they are:
> > [1] https://github.com/tc39/proposal-decorators
> > [2]
> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
> > Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
> > escreveu:
> > >
> > > In the ~maybe long~ future , after the current decorators proposal
> [1], we can start thinking about a Method Parameter Decorator (already
> proposed [2]), we could do something like:
> > >
> > > ``` js
> > > class Foo {
> > > constructor(@field foo) {
> > > }
> > > }
> > > ```
> > >
> > > In my opinion, it would be a much more powerful approach
> > > Em qua, 28 de nov de 2018 às 16:33, Simo Costa <
> andrysimo1...@gmail.com> escreveu:
> > > >
> > > > In costructor functions and in the constructor() method in ES6
> classes is easily to fall in the following pattern:
> > > >
> > > > F(par1, par2, ..., parN) {
> > > > this.par1 = par1;
> > > > this.par2 = par2;
> > > > ...
> > > > this.parN = parN;
> > > > }
> > > >
> > > >
> > > > So my proposal is to avoid those repetitions by prefixing a dot .
> to each parameter:
> > > >
> > > > F(.par1, .par2, ..., .parN) {}
> > > >
> > > > Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
> > > >
> > > >
> > > >
> > > > ___
> > > > es-discuss mailing list
> > > > es-discuss@mozilla.org
> > > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> > >
> > >
> > > --
> > > Atenciosamente,
> > >
> > > Augusto Borges de Moura
> >
> >
> >
> > --
> > Atenciosamente,
> >
> > Augusto Borges de Moura
> > ___
> > 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: Proposal for faster this assignments in constructor functions
Dart has something like this:
https://www.dartlang.org/guides/language/language-tour#constructors
```dart
class Point {
num x, y;
// Syntactic sugar for setting x and y
// before the constructor body runs.
Point(this.x, this.y);
}
```
I could see a form of BindingElement (et al) that allows `this` or `this` `.`
BindingIdentifier:
```js
class Point {
constructor(this.x, this.y) {}
}
new Point(10, 20).x; // 10
class Foo {
constructor(this.x, { y: this.z, …this }) {}
}
const f = new Foo(1, { y: 2, w: 3 });
f.x; // 1
f.z; // 2
f.w; // 3
```
TypeScript has something similar for constructors in the form of “parameter
property assignments”, but they are triggered by the presence of an modifier
(i.e. `public`, `private`, `protected`, `readonly`).
Ron
From: es-discuss On Behalf Of Claude Pache
Sent: Wednesday, November 28, 2018 11:46 AM
To: Simo Costa
Cc: es-discuss@mozilla.org
Subject: Re: Proposal for faster this assignments in constructor functions
Le 28 nov. 2018 à 19:32, Simo Costa
mailto:andrysimo1...@gmail.com>> a écrit :
In costructor functions and in the constructor() method in ES6 classes is
easily to fall in the following pattern:
F(par1, par2, ..., parN) {
this.par1 = par1;
this.par2 = par2;
...
this.parN = parN;
}
So my proposal is to avoid those repetitions by prefixing a dot . to each
parameter:
F(.par1, .par2, ..., .parN) {}
Simple but quite useful. More info here:
https://github.com/jfet97/proposal-fast-this-assignments
Simple, but a brand new and nonobvious syntax, for a relatively limited use
case.
Also, just one dot is too inconspicuous. At the very least, I’d prefer:
```js
function F(this.par1, this.par2, this.par3) { }
```
whose meaning is somewhat more intuitive.
Also noteworthy: in many cases, you can already reduce repetition with the
combination of `Object.assign`, improved syntax literal, and imagination; see:
http://2ality.com/2014/12/es6-oop.html#use-cases-for-objectassign
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
Just dropping in real quick to correct a couple things.
First, `arguments` itself is *not* deprecated in strict mode. Things
like `arguments.caller` are deprecated and throw a `TypeError` when
the corresponding function is in strict mode.
Second, some of you all were looking to use `Object.assign` to help
explain. You'd need to do this for it to be correct:
```js
class C {
constructor(a, b, ..., y, z) {
Object.assign(this, {a, b, ..., y, z})
}
}
```
(Not TC39, just I felt the need to correct people here.)
-
Isiah Meadows
cont...@isiahmeadows.com
www.isiahmeadows.com
On Wed, Nov 28, 2018 at 5:50 PM Augusto Moura wrote:
>
> I forgot the links in my last email, here they are:
> [1] https://github.com/tc39/proposal-decorators
> [2]
> https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
> Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
> escreveu:
> >
> > In the ~maybe long~ future , after the current decorators proposal [1], we
> > can start thinking about a Method Parameter Decorator (already proposed
> > [2]), we could do something like:
> >
> > ``` js
> > class Foo {
> > constructor(@field foo) {
> > }
> > }
> > ```
> >
> > In my opinion, it would be a much more powerful approach
> > Em qua, 28 de nov de 2018 às 16:33, Simo Costa
> > escreveu:
> > >
> > > In costructor functions and in the constructor() method in ES6 classes is
> > > easily to fall in the following pattern:
> > >
> > > F(par1, par2, ..., parN) {
> > > this.par1 = par1;
> > > this.par2 = par2;
> > > ...
> > > this.parN = parN;
> > > }
> > >
> > >
> > > So my proposal is to avoid those repetitions by prefixing a dot . to
> > > each parameter:
> > >
> > > F(.par1, .par2, ..., .parN) {}
> > >
> > > Simple but quite useful. More info here:
> > > https://github.com/jfet97/proposal-fast-this-assignments
> > >
> > >
> > >
> > > ___
> > > es-discuss mailing list
> > > es-discuss@mozilla.org
> > > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > --
> > Atenciosamente,
> >
> > Augusto Borges de Moura
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
> ___
> 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: Proposal for faster this assignments in constructor functions
I forgot the links in my last email, here they are:
[1] https://github.com/tc39/proposal-decorators
[2]
https://docs.google.com/document/d/1Qpkqf_8NzAwfD8LdnqPjXAQ2wwh8BBUGynhn-ZlCWT0
Em qua, 28 de nov de 2018 às 20:48, Augusto Moura
escreveu:
>
> In the ~maybe long~ future , after the current decorators proposal [1], we
> can start thinking about a Method Parameter Decorator (already proposed [2]),
> we could do something like:
>
> ``` js
> class Foo {
> constructor(@field foo) {
> }
> }
> ```
>
> In my opinion, it would be a much more powerful approach
> Em qua, 28 de nov de 2018 às 16:33, Simo Costa
> escreveu:
> >
> > In costructor functions and in the constructor() method in ES6 classes is
> > easily to fall in the following pattern:
> >
> > F(par1, par2, ..., parN) {
> > this.par1 = par1;
> > this.par2 = par2;
> > ...
> > this.parN = parN;
> > }
> >
> >
> > So my proposal is to avoid those repetitions by prefixing a dot . to each
> > parameter:
> >
> > F(.par1, .par2, ..., .parN) {}
> >
> > Simple but quite useful. More info here:
> > https://github.com/jfet97/proposal-fast-this-assignments
> >
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
--
Atenciosamente,
Augusto Borges de Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
In the ~maybe long~ future , after the current decorators proposal
[1], we can start thinking about a Method Parameter Decorator (already
proposed [2]), we could do something like:
``` js
class Foo {
constructor(@field foo) {
}
}
```
In my opinion, it would be a much more powerful approach
Em qua, 28 de nov de 2018 às 16:33, Simo Costa
escreveu:
>
> In costructor functions and in the constructor() method in ES6 classes is
> easily to fall in the following pattern:
>
> F(par1, par2, ..., parN) {
> this.par1 = par1;
> this.par2 = par2;
> ...
> this.parN = parN;
> }
>
>
> So my proposal is to avoid those repetitions by prefixing a dot . to each
> parameter:
>
> F(.par1, .par2, ..., .parN) {}
>
> Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Atenciosamente,
Augusto Borges de Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
I assumed that `F` was called with `new`, providing a valid `this` object
too and I've used the object spread syntax to avoid a function call.
Anyway I prefer
```js
F(par1, par2, ..., parN) {
this.par1 = par1;
this.par2 = par2;
...
this.par3 = par3;
}
```
to this:
```js
F(arg) {
let {par1, par2, ..., parN} = arg;
Object.assign(this, arg);
}
```
Because there is no function call (` Object.assign `), no useless object
creation (when you pass arguments) nor duplication. The first should be
faster. And it is obviously clearer.
So:
```js
F(.par1, .par2, ..., .parN) {}
```
Could be fast too. Maybe also clear, because when you learn what it
does...you cannot misundertood it later.
Il giorno mer 28 nov 2018 alle ore 22:51 Ranando King
ha scritto:
> Arguments is only deprecated in strict mode.
>
> ```js
> F(arg) {
> let {par1, par2, ..., parN} = arg;
> Object.assign(this, arg);
> }
> ```
>
> This version works in strict mode, but it's less clear what parameters
> should be passed. I used `Object.assign` because I assumed that `F` was
> called with `new`, providing a valid `this` object. Otherwise, your
> original example would either throw in strict mode, or add your parameters
> to "global", unless it was called with `Function.prototype.call`.
>
> On Wed, Nov 28, 2018 at 3:36 PM Simo Costa
> wrote:
>
>> Ops I saw the now ahahah sorry. But anyway there is a function call and
>> an object creation and you are forced to pass arguments using an object
>> (not so bad but...another object creation).
>> To avoid the function call I would do:
>> ```js
>> F({par1, par2, ..., parN}) {
>> this = {...arguments[0]};
>> }
>> ```
>> Another thing...`arguments` is deprecated, right?
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
Arguments is only deprecated in strict mode.
```js
F(arg) {
let {par1, par2, ..., parN} = arg;
Object.assign(this, arg);
}
```
This version works in strict mode, but it's less clear what parameters
should be passed. I used `Object.assign` because I assumed that `F` was
called with `new`, providing a valid `this` object. Otherwise, your
original example would either throw in strict mode, or add your parameters
to "global", unless it was called with `Function.prototype.call`.
On Wed, Nov 28, 2018 at 3:36 PM Simo Costa wrote:
> Ops I saw the now ahahah sorry. But anyway there is a function call and an
> object creation and you are forced to pass arguments using an object (not
> so bad but...another object creation).
> To avoid the function call I would do:
> ```js
> F({par1, par2, ..., parN}) {
> this = {...arguments[0]};
> }
> ```
> Another thing...`arguments` is deprecated, right?
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
Ops I saw the now ahahah sorry. But anyway there is a function call and an
object creation and you are forced to pass arguments using an object (not
so bad but...another object creation).
To avoid the function call I would do:
```js
F({par1, par2, ..., parN}) {
this = {...arguments[0]};
}
```
Another thing...`arguments` is deprecated, right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
No. It has to be arguments[0]. Notice the braces around the argument list?
This is meant to use destructured arguments. The argument list in this case
has only 1 element, hence the `[0]`.
On Wed, Nov 28, 2018 at 3:26 PM Simo Costa wrote:
> @Ranando
>
> I think you meant:
> ```js
> F({par1, par2, ..., parN}) {
> Object.assign(this, arguments);
> }
> ```
> This is briefly explained on github, anyway you'll get an undesired
> 'length' property.
>
> Il giorno mer 28 nov 2018 alle ore 22:20 Ranando King
> ha scritto:
>
>> What about this:
>>
>> ```js
>> F({par1, par2, ..., parN}) {
>> Object.assign(this, arguments[0]);
>> }
>> ```
>>
>> On Wed, Nov 28, 2018 at 2:20 PM Simo Costa
>> wrote:
>>
>>> @Claude
>>>
>>> Your suggestion is still too much verbose/ripetitive in my opinion
>>> because you repeat the `this`keyword. I agree with the "limited use cases"
>>> of my proposal but not with your concerns about the syntax, but I am open
>>> for improvements on it.
>>> I do not think that it could bring more mistuderstading than the
>>> introduction of the rest/spread syntax has brought.
>>>
>>> And about the Object.assign solution, there are always (theoretically)
>>> an object creation and a function call, as well as the repetition of the
>>> parameters.
>>> `Object.assign(this, {x, y});`
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> 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: Proposal for faster this assignments in constructor functions
@Ranando
I think you meant:
```js
F({par1, par2, ..., parN}) {
Object.assign(this, arguments);
}
```
This is briefly explained on github, anyway you'll get an undesired
'length' property.
Il giorno mer 28 nov 2018 alle ore 22:20 Ranando King
ha scritto:
> What about this:
>
> ```js
> F({par1, par2, ..., parN}) {
> Object.assign(this, arguments[0]);
> }
> ```
>
> On Wed, Nov 28, 2018 at 2:20 PM Simo Costa
> wrote:
>
>> @Claude
>>
>> Your suggestion is still too much verbose/ripetitive in my opinion
>> because you repeat the `this`keyword. I agree with the "limited use cases"
>> of my proposal but not with your concerns about the syntax, but I am open
>> for improvements on it.
>> I do not think that it could bring more mistuderstading than the
>> introduction of the rest/spread syntax has brought.
>>
>> And about the Object.assign solution, there are always (theoretically)
>> an object creation and a function call, as well as the repetition of the
>> parameters.
>> `Object.assign(this, {x, y});`
>>
>>
>>
>>
>>
>>
>> ___
>> 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: Proposal for faster this assignments in constructor functions
What about this:
```js
F({par1, par2, ..., parN}) {
Object.assign(this, arguments[0]);
}
```
On Wed, Nov 28, 2018 at 2:20 PM Simo Costa wrote:
> @Claude
>
> Your suggestion is still too much verbose/ripetitive in my opinion because
> you repeat the `this`keyword. I agree with the "limited use cases" of my
> proposal but not with your concerns about the syntax, but I am open for
> improvements on it.
> I do not think that it could bring more mistuderstading than the
> introduction of the rest/spread syntax has brought.
>
> And about the Object.assign solution, there are always (theoretically) an
> object creation and a function call, as well as the repetition of the
> parameters.
> `Object.assign(this, {x, y});`
>
>
>
>
>
>
> ___
> 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: Proposal for faster this assignments in constructor functions
@Claude
Your suggestion is still too much verbose/ripetitive in my opinion because
you repeat the `this`keyword. I agree with the "limited use cases" of my
proposal but not with your concerns about the syntax, but I am open for
improvements on it.
I do not think that it could bring more mistuderstading than the
introduction of the rest/spread syntax has brought.
And about the Object.assign solution, there are always (theoretically) an
object creation and a function call, as well as the repetition of the
parameters.
`Object.assign(this, {x, y});`
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal for faster this assignments in constructor functions
> Le 28 nov. 2018 à 19:32, Simo Costa a écrit :
>
> In costructor functions and in the constructor() method in ES6 classes is
> easily to fall in the following pattern:
>
> F(par1, par2, ..., parN) {
> this.par1 = par1;
> this.par2 = par2;
> ...
> this.parN = parN;
> }
>
> So my proposal is to avoid those repetitions by prefixing a dot . to each
> parameter:
> F(.par1, .par2, ..., .parN) {}
>
> Simple but quite useful. More info here:
> https://github.com/jfet97/proposal-fast-this-assignments
>
>
Simple, but a brand new and nonobvious syntax, for a relatively limited use
case.
Also, just one dot is too inconspicuous. At the very least, I’d prefer:
```js
function F(this.par1, this.par2, this.par3) { }
```
whose meaning is somewhat more intuitive.
Also noteworthy: in many cases, you can already reduce repetition with the
combination of `Object.assign`, improved syntax literal, and imagination; see:
http://2ality.com/2014/12/es6-oop.html#use-cases-for-objectassign
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal for faster this assignments in constructor functions
In costructor functions and in the constructor() method in ES6 classes is
easily to fall in the following pattern:
F(par1, par2, ..., parN) {
this.par1 = par1;
this.par2 = par2;
...
this.parN = parN;
}
So my proposal is to avoid those repetitions by prefixing a dot *.* to
each parameter:
F(.par1, .par2, ..., .parN) {}
Simple but quite useful. More info here:
https://github.com/jfet97/proposal-fast-this-assignments
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
