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`. On Sun, Dec 2, 2018 at 3:05 PM Augusto Moura <[email protected]> wrote: > 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. > > [1] https://github.com/rdking/proposal-common-member-modifiers#motivation > [2] https://tc39.github.io/process-document/ > Em dom, 2 de dez de 2018 às 04:49, Ranando King <[email protected]> > escreveu: > > > > 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. > > > > https://github.com/rdking/proposal-common-member-modifiers > > _______________________________________________ > > es-discuss mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > -- > Atenciosamente, > > Augusto Borges de Moura >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
