Quantcast

Field initializers

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Field initializers

just nobody
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

Michael J. Ryan
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

just nobody
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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

Jordan Harband
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 <[hidden email]> 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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

just nobody
I usually just use Classes and constructor functions for simple data structures. Only allowing this for private fields seems counter-intuitive to that. Why not both?

On Sat, Mar 18, 2017 at 2:05 PM Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

Augusto Moura
In reply to this post by just nobody
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)

```.js
// This will throw a SyntaxError?
class Rectangle {
  constructor(own #x, own #y, own name) {}
}
```

There's a new proposal using the `own` keyword in class fields declaration (https://github.com/erights/Orthogonal-Classes). It might fit perfectly.
--
Augusto B. Moura

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

T.J. Crowder-2
In reply to this post by Jordan Harband
On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

just nobody
> 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.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.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 <[hidden email]> wrote:
On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Field initializers

Jordan Harband
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 <[hidden email]> 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.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.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 <[hidden email]> wrote:
On Sat, Mar 18, 2017 at 6:04 PM, Jordan Harband <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
Interesting concept... What about inheritance?

--
Michael J. Ryan - [hidden email] - 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" <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Loading...