search

tc39 / proposal-class-public-fields

Stage 2 proposal for public class fields in ECMAScript
https://tc39.github.io/proposal-class-public-fields/
487 stars 25 forks source link

Proposal clarification #52

Open jdalton opened 8 years ago

jdalton commented 8 years ago

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 commented 8 years ago

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

jeffmo commented 8 years ago

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 commented 8 years ago

@jeffmo Sure, that would rock :metal:!

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 commented 7 years ago

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.