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
<[email protected]> 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
<[email protected]> 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
[email protected]
https://mail.mozilla.org/ listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
