search

tc39 / proposal-class-public-fields

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

Helping with progress #55

Closed RWOverdijk closed 7 years ago

RWOverdijk commented 7 years ago

Hello.

I'm new to this proposal stuff, but I want to get involved. This proposal, along with one other are especially interesting to me. How can I help move things forward?

Sorry if this isn't the place for these questions. Feel free to lecture me and plaster this issue with links so I can RTFM.

Thanks!

jeffmo commented 7 years ago

Hey @RWOverdijk! Thanks for offering your support!

At this point the remaining details to be worked through are roughly:

1) Whether to use DefineProperty vs Set 2) Whether to use a = token or a new := token

The two are closely intermingled: sSme argue for := to mean Define and = to mean Set, others don't feel strongly, and some feel that = is most natural/precedented regardless of Define/Set. Either way it's a subjective design problem and probably just needs to be chosen with an understanding that perfection isn't the goal.

(1) is a trade-off that will serve some use cases and leave others behind no matter which way we go.

To be fully honest with you: I'm not sure there's much more to be learned in this space with these 2 remaining questions and we just need to move forward, but obviously ears are wide open for new thoughts/ideas.

@littledan will be bringing this to the next tc39 meeting for discussion and (hopefully) closure so that we can move toward Stage 3.

RWOverdijk commented 7 years ago

@jeffmo Silly question perhaps, but isn't it the way typescript and babel implement it desirable? I've been working with it for quite some time now and I really like it. Especially the way they work with decorators (the other proposal I really want to see make it).

loganfsmyth commented 7 years ago

Babel implements the spec, so Babel would just change the syntax if TC39 decided it was better. Also Babel is kind of both since it uses DefineProperty if you're using decorators-legacy, but Set otherwise, unless you pass spec: true which most people don't know about.

jeffmo commented 7 years ago

I suspect @RWOverdijk was suggesting that the spec should just largely follow what Babel does -- and, for the most part, it does.

In general I believe "good experiences in babel" is an excellent proxy for "will work well in practice" for proposals of this particular kind (read: easy compilable proposals with few caveats in the compiler output), which is why I'm not too worried about the status quo of the proposal - which aligns mostly with Babel.

There are others who have other kinds of considerations as well though -- Things like retaining option value for other/future proposals that may interact with fields. Decorators is one such example, but it's largely accounted for in this proposal. Another is the possibility of a future "const fields" proposal -- which is why DefineProperty is important. Etc...

RWOverdijk commented 7 years ago

@jeffmo That's an interesting point, because coming from PHP I do sometimes miss const fields. Now I solve it with a public static property constants and freezing it.

I'm glad to hear this proposal sits well. Again, if I could help in any way, let me know :)