New: proposal-common-member-modifiers

[Ranando King]

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 <augusto.borgesm at gmail.com>
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 <kingmph at gmail.com>
> 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
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> --
> Atenciosamente,
>
> Augusto Borges de Moura
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20181202/64e47f77/attachment-0001.html>