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
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?
>
>
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
``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
```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,
@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
> ```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
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)
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
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)
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
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
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
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,
-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?
>
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
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
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
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
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
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`,
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]};
}
```
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,
@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,
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
@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
> 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
27 matches
Mail list logo
