pzuraq
commented
1 year ago Decorators on POJOs were originally considered as part of this proposal early on, along with decorators on functions and function parameters. However, these additional features increased the scope of the proposal, and were part of the reason that it has taken > 5 years to advance to stage 3. Getting consensus on the design of all of the different types of decorators that we could add to the language, all at once, would likely stall this proposal for additional years.
Much like classes, which were designed in phases with more features added over time (e.g. class fields, private fields, static blocks), the plan with decorators is to continue to add more types over time. Class decorators were chosen to start with because it is currently not possible to metaprogram with class elements like methods and fields. You can use the decoration pattern with POJOs today, though it is less ergonomic and readable, to be sure.
Given this history and context, POJO decorators will not be added to this proposal. It will continue to be tightly scoped to class and class element decorators. Additionally, since the proposal is now at stage 3, it would not be possible to expand the scope so much (at least not without potentially moving back to stage 2).
That said, this proposal does not prevent us from adding POJO decorators in the future, and I think it's likely that they will be explored at some point in a future proposal.
Restricting decorators to only generate classes is causing unnecessary limitations for library authors. Example:
https://github.com/facing-dev/vue-facing-decorator/discussions/44
Please don't follow in the footsteps of Chrome team making everything class dependent, and creating a mess of a developer community that doesn't agree with these decisions:
https://github.com/WICG/webcomponents/issues/587#issuecomment-737091825