New: proposal-common-member-modifiers
I'm of the opinion this is what decorators are for.
For one token (+ an import) more, you could use decorators instead. And BTW, it's been suggested already that a standard decorator library should exist, just IIUC (I'm not part of TC39) it's not yet determined what should be in it.
Isiah Meadows contact at isiahmeadows.com, www.isiahmeadows.com
I get that decorators "can" perform the same task, but these are features that are standard in the language today. Once we start defining data properties on classes, there will be an immediate need to define the attributes of those properties. Yes, decorators can fill the need, but unless a standard library is provided to perform these tasks, there will certainly be multiple different takes on how such decorators should work. By defining them directly into the language like this, not only do we get a well defined approach to declaring properties with the desired attributes, but we avoid the additional complexity of decorator implementation for an otherwise trivial task.
...at least, that's how I'm thinking of it. I'm also working on 1 last
proposal, proposal-class-modifiers with the intent of adding abstract and
final to class declarations where abstract class would prevent
instantiation of the class and final class would prevent inheritance of
the class.
I just want to make it perfectly clear to everyone that neither I am a member of TC39
Best
Extracted from the proposal 1:
Instead of waiting for the community to define and agree upon decorators for these purposes, why not define them now?
In my opinion this is not how things should be done, in my opinion we actually should follow user-land patterns and help modifying/extending the language in this patterns pain points. We saw that in almost every new feature in the language since Harmony (not a coincidence, it's was actually decided to be this way), community agreement is a important factor in the process (I really don't know why it's not in the TC39 process document 2, maybe is implied?). A lot of problems in Javascript ~and probably all other languages in existence~ arose from expected usefulness, just to be tagged as a foot gun or bad design by the community, and not used at all.
That being said, I think decorators already provide all the need for this "runtime-modifiers" keywords, and new keyword-like modifiers will only add complexity to the language, as we would have 2 declarative ways of doing the same thing (or worse, the community decide in a different behavior for the analogue decorators, and probably one of the ways would be discouraged and become spec garbage).
PS.: Sure there are cases were the community is really divided and things don't move because of that, and some of this cases are merged in the spec without total agreement at the end. But in my opinion this slow process and discussion is a good thing, we cannot merge something just to because it seems like a good feature. Also I'm not a TC39 member, it's my opinion based in similar discussions in the past, maybe some real member can clarify it better or correct me if I'm wrong.
Decorators are stage 2. No major implementation implements them, and Babel dropped them and had to completely reimplement their semantics after a major semantic overhaul in the proposal.
I also agree that the community should have a hand in the process. I don't,
however, agree that waiting for the community to come to a consensus by
providing definitions that exist in the wild is a good idea. TC39 tends
toward not accepting proposals that break what already exists in the wild.
I'm submitting this proposal with the intent of having the community decide
on these important features before they're out in the wild so as to
prevent the natural confusion that will ensue as people release their own
spin on how these things should be defined. I'd even be happy with a set of
well-defined decorators, as long as they are a standard part of the
language. Whether or not the @ is in front of them is of little merit to
me.
The point of the proposal is to make the standard parts of a property
descriptor also expressible in a class definition. This is something that
will be immediately desirable with any implementation of declarative data
members in a class.
Since some form of data is going to land in ES class syntax, it would be a good idea if the capabilities of a property descriptor were also exposed for all public properties.
rdking/proposal