Proposal clarification

[jdalton]

I was introduced to this proposal from a Babel issue on supporting computed class properties. Is that the gist of this proposal? If it is I think it could use a mention of computed properties in its description or spec text because at first glance that was hard to pick out.

[danharper]

This proposal's for class properties in general (just called "public fields", I assume to differentiate from possible future private properties).

[jeffmo]

I'm not really sure what we need to say here?

It's in the spec'd grammar (see grammar specified with PropertyName). I guess we could add some example code in the repo's description... Is that what you mean?

[jdalton]

@jeffmo Sure, that would rock 🤘!

Computed property names for classes are great!
I had no idea there was a proposal addressing it.

I saw others hit by the lack of them recently too. \cc @arackaf

[JTallis]

I'm a little late to the party but I hope this makes it into the next standard. I can live with defining instance properties (if that is what they're called) in the constructor but the following for static properties seems to grind my gears:

class Foo {}
Foo.staticProp = true;

I don't know about anyone else but despite the fact that this works, I feel as if properties need to be defined before they are "seen" to be used. It doesn't flow nicely to read code from top to bottom and hit a property that is defined down the bottom of a potentially large file. Of course I could very well be biased seeing as my background is PHP.