The public one is the one I was thinking of when I said it shouldn't conflict. (I don't see the private spec going anywhere to be honest with that syntax, but if it does that would be interesting).

As for the conversion, yes that would be a good conversion for the first example. In the second example putting things outside places them in a different scope. Imagine you had multiple classes defined and they had their own instances member.

As for static constructors a more contrived example would be a memoization operation where one does initial work or generation in the static constructor rather than initialization.

```
class MathLibrary
{
    static table = {};
    static constructor()
    {
        // Common cases
        for (let i = 0; i < 100; ++i)
        {
            MathLibrary.table[x] = // something complex and time consuming
        }
    }
    static Calculate(x)
    {
        if (MathLibrary.table.hasOwnProperty(x))
        {
            return MathLibrary.table[x];
        }
        else
        {
            let complexCalculation = // something complex and time consuming
            MathLibrary.table[x] = complexCalculation;
            return complexCalculation;
        }
    }
}
```
> Keep in mind that if something is a "static" in the ES6 class method sense, you will never be able to do `this.instances` to get it because the property does not live on `this`, it lives on the constructor.
I'll have to think about that. Might need another proposal. I always like to think about static methods and variables as being shared among all instances. Would be nice to get that kind of meaning also. Essentially aliases. Accessing static methods inside of a instance methods requires using the type name which I find less than ideal. Probably a personal preference though.


    On Wednesday, January 25, 2017 11:41 PM, Logan Smyth <loganfsmyth at gmail.com> wrote:
 

 So we're on the same page, in the active proposal list (https://github.com/tc39/proposals) you'll find* Public Fields: https://tc39.github.io/proposal-class-public-fields/* Private Fields: https://github.com/tc39/proposal-private-fields
Public Fields includes a syntax for static properties that would convert your example to something like
```class Multiton {    static instances = {};
    constructor(name) {
        if (Multiton.instances.hasOwnProperty(name)) throw `Multiton name already used`;
        Multiton.instances[name] = this;
    }
}
```

though I don't know I'd personally do this in this instance, rather than putting it outside the class, like
```
const instances = {};class Multiton {    constructor(name) {
        if (instances.hasOwnProperty(name)) throw `Multiton name already used`;
        instances[name] = this;
    }
}
```
Keep in mind that if something is a "static" in the ES6 class method sense, you will never be able to do `this.instances` to get it because the property does not live on `this`, it lives on the constructor. I'm unsure if the private fields proposal would allow `static #instance = {};` as a static with `#instance[name] = this;` inside the constructor.
On Wed, Jan 25, 2017 at 8:40 PM, Brandon Andrews <warcraftthreeft at sbcglobal.net> wrote:

The initial proposal for discussion is below:


https://github.com/sirisian/ ecmascript-static-constructor

I don't believe this conflicts with other proposals yet, nor any future proposals. Essentially it adds static members in a very compact syntax with minimal grammar changes required.

What I foresee happening years from now is public, private, and static member syntax will be added. Much like how public members are defined in the constructor for the moment the static constructor would be the way to define static members of the class for now.

Thoughts?
______________________________ _________________
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/20170126/530e7aa8/attachment-0001.html>

The public one is the one I was thinking of when I said it shouldn't conflict. (I don't see the private spec going anywhere to be honest with that syntax, but if it does that would be interesting).

As for the conversion, yes that would be a good conversion for the first example. In the second example putting things outside places them in a different scope. Imagine you had multiple classes defined and they had their own instances member.

As for static constructors a more contrived example would be a memoization operation where one does initial work or generation in the static constructor rather than initialization.

```
class MathLibrary
{
    static table = {};
    static constructor()
    {
        // Common cases
        for (let i = 0; i < 100; ++i)
        {
            MathLibrary.table[i] = // something complex and time consuming
        }
    }
    static Calculate(x)
    {
        if (MathLibrary.table.hasOwnProperty(x))
        {
            return MathLibrary.table[x];
        }
        else
        {
            let complexCalculation = // something complex and time consuming
            MathLibrary.table[x] = complexCalculation;
            return complexCalculation;
        }
    }
}
```
> Keep in mind that if something is a "static" in the ES6 class method sense, you will never be able to do `this.instances` to get it because the property does not live on `this`, it lives on the constructor.

I'll have to think about that. Might need another proposal. I always like to think about static methods and variables as being shared among all instances. Would be nice to get that kind of meaning also. Essentially aliases. Accessing static methods inside of a instance methods requires using the type name which I find less than ideal. Probably a personal preference though.

The public one is the one I was thinking of when I said it shouldn't conflict. (I don't see the private spec going anywhere to be honest with that syntax, but if it does that would be interesting).

As for the conversion, yes that would be a good conversion for the first example. In the second example putting things outside places them in a different scope. Imagine you had multiple classes defined and they had their own instances member.

As for static constructors a more contrived example would be a memoization operation where one does initial work or generation in the static constructor rather than initialization.

```
class MathLibrary
{
    static table = {};
    static constructor()
    {
        // Common cases
        for (let i = 0; i < 100; ++i)
        {
            MathLibrary.table[x] = // something complex and time consuming
        }
    }
    static Calculate(x)
    {
        if (MathLibrary.table.hasOwnProperty(x))
        {
            return MathLibrary.table[x];
        }
        else
        {
            let complexCalculation = // something complex and time consuming
            MathLibrary.table[x] = complexCalculation;
            return complexCalculation;
        }
    }
}
```
> Keep in mind that if something is a "static" in the ES6 class method sense, you will never be able to do `this.instances` to get it because the property does not live on `this`, it lives on the constructor.

I'll have to think about that. Might need another proposal. I always like to think about static methods and variables as being shared among all instances. Would be nice to get that kind of meaning also. Essentially aliases. Accessing static methods inside of a instance methods requires using the type name which I find less than ideal. Probably a personal preference though.