TC39 Decorators on 2022-05-18

00:31	<rbuckton>	I've updated https://github.com/tc39/proposal-grouped-and-auto-accessors with initial spec text and plan to bring it back to committee in June for possible advancement. The spec text is aligned with the proposed spec text for Stage 3 Decorators, and expands upon the current `accessor` keyword form as we discussed when we added the `accessor` keyword to the Decorators proposal.
00:32	<rbuckton>	Full spec text is at https://tc39.es/proposal-grouped-and-auto-accessors. I will update the website link in the GitHub Repo as soon as a chair is able to fix my permissions in the repo.
00:40	<rbuckton>	pzuraq: I wonder if we need a more general name than "ClassElementDefinition Record", considering object literals also have MethodDefinition elements. In the auto-accessors proposal I add a second thing to an Object Literal that produces a "ClassElementDefinition Record", making it feel even more out of place in those algorithms.
14:27	<pzuraq>	yeah the overlap there is a bit odd for sure
14:27	<pzuraq>	open to naming suggestions
15:56	<ljharb>	ljharb: can you remove zenparsing@gmail.com from the decorators meeting invites? There are two invites also, since we have two different times done
16:41	<rbuckton>	open to naming suggestions It could just be as simple as "MemberDefinition Record", "PropertyDefinition Record", or "ElementDefinition Record". "PropertyDefinition" aligns with "PropertyDescriptor" even if it has always felt out of place calling a method a property. I'm personally partial to "MemberDefinition", since it is consistent with terms like "class member", "object literal member", and possible future things like enum members.
17:01	<rbuckton>	During the Decorators call yesterday we discussed whether to bring https://github.com/tc39/proposal-decorators/issues/465 to plenary in June. pzuraq indicated that if the committee agreed to this change that he would not pursue decorator metadata and would leave that up to other delegates to decide whether to champion that proposal. Since there were only a few people in attendance, I wanted to get feedback from others in the group whether we should continue to pursue metadata support in some form if decorators have the ability to add any kind of extra initializer regardless of placement.
17:09	<rbuckton>	The state of using decorators to provide runtime metadata is somewhat up in the air, with several different solutions proposed: An opaque immutable object passed to every decorator within a class that is installed as `constructor[Symbol.metadata]`. Decorators would need to use a WeakMap to associate metadata, and provide their own APIs for reading metadata (i.e., metadata is private). A normal mutable object passed to every decorator within a class that is installed as `constructor[Symbol.metadata]`. Decorators could either write directly to the object or use a WeakMap and their own API (i.e., metadata can be public or private). An object passed to every decorator within a class, with methods that can be used to read and write metadata. The results of which would be stored as an object installed as `constructor[Symbol.metadata]` (i.e., metadata is public).
17:13	<rbuckton>	Public metadata can be achieved with (1) by using a second decorator. Private metadata can be achieved with (3) by storing an object in the public metadata that is only used as a WeakMap key.
17:15	<pzuraq>	It could just be as simple as "MemberDefinition Record", "PropertyDefinition Record", or "ElementDefinition Record". "PropertyDefinition" aligns with "PropertyDescriptor" even if it has always felt out of place calling a method a property. I'm personally partial to "MemberDefinition", since it is consistent with terms like "class member", "object literal member", and possible future things like enum members. I like `MemberDefinition` as well, I think that covers both nicely
17:18	<rbuckton>	With #465 public and private metadata can still be achieved, but would depend on userland implementations (similar to `reflect-metadata`): Private Metadata: use `addInitializer(cb, "class")` to add a class "extra" initializer regardless of decorator placement. The callback receives the constructor as the `this` binding and can store the constructor in a WeakMap. Public Metadata: use `addInitializer(cb, "class")` to add a class "extra" initializer regardless of decorator placement. The callback receives the constructor as the `this` binding can can store the metadata in a property on the constructor. Caveat: for performance reasons, the property should be declared on the class as well.
17:20	<rbuckton>	My open questions are: If we bring #465 to plenary, is that likely to shut down any further progress towards decorator metadata? Are there use cases for #465 outside of metadata?
17:22	<rbuckton>	Each use case for #465 that has come to mind for me so far is very metadata-like. For example: React's `propTypes` is essentially runtime metadata.