Adds Decorator Metadata #10

pzuraq · 2023-03-07T19:40:23Z

Adds the spec implementation for the current iteration of Decorator Metadata. Since this builds off the decorators proposal, this PR is currently being made against that proposals PR. Once that proposal is merged into the spec fully, this branch will be rebased and a new PR will be made.

Updates - Refactor to use ClassElementDefinition more extensively - Separate parsing class elements and defining them so that we can control the order of definition and decorator application - Extract and centralize class element decoration into a single place - Fix completions in ClassDefinitionEvaluation (need to reset the env after each possible abrupt completion). - Refactor adding private methods to instance to pull directly from `Class.[[Elements]]`, so we don't have multiple sources of truth for the elements that are defined on a class. `Class.[[Elements]]` is the canonical source of truth after ClassDefinitionEvaluation, and any operations afterward such as instantiation should base themselves on that. - Refactor to use anonymous function syntax.

Remove dynamic [[HomeObject]] from decorator return values

…allable Throw an error if the value passed to `addInitializer` is not callable

Set the name of the `addInitializer` function

For more details, see this issue: tc39/proposal-decorators#487

Remove setFunctionName from decorator application

Call decorators with the natural `this` value

bakkot · 2023-04-26T22:27:11Z

spec.html

@@ -25194,39 +25210,43 @@ <h1>
        1. Set the running execution context's LexicalEnvironment to _env_.
        1. Let _instanceExtraInitializers_ be a new empty List.
        1. Let _staticExtraInitializers_ be a new empty List.
+        1. Let _metadataParent_ be ? Get(_constructorParent_, @@metadata).
+        1. If _metadataParent_ is *undefined*, let _metadataParent_ be %Object.prototype%.


Should we bottom out in null instead of %Object.prototype%?

Agreed, and updated, thanks for calling that out!

bakkot · 2023-04-26T22:44:45Z

spec.html

        1. If _newF_ is an abrupt completion, then
          1. Set the running execution context's PrivateEnvironment to _outerPrivateEnvironment_.
          1. Return ? _result_.
        1. Set _F_ to _newF_.[[Value]].
+        1. Perform ! DefinePropertyOrThrow(_F_, @@metadata, PropertyDescriptor { [[Value]]: _metadataObj_, [[Writable]]: *true*, [[Enumerable]]: *false*, [[Configurable]]: *true* }).


Unfortunately the class object might have gotten swapped out by a class decorator (or the class could have been mutated), which might cause this to fail in a variety of ways. So this needs to be ?.

Ah good point, I'll revise this asap

syg · 2023-05-10T19:44:58Z

spec.html

@@ -25194,39 +25210,43 @@ <h1>
        1. Set the running execution context's LexicalEnvironment to _env_.
        1. Let _instanceExtraInitializers_ be a new empty List.
        1. Let _staticExtraInitializers_ be a new empty List.
+        1. Let _metadataParent_ be ? Get(_constructorParent_, @@metadata).


So _constructorParent_ gets defaulted to %Function.prototype% when there is no extends clause. Which means someone can assign to Function.prototype[Symbol.metadata] to be the default parent for all metadata. That seems... not good? Should we do this Get only if |ClassHeritage?| is present?

I like making the Get conditional. Alternatively, we could make Function.prototype[Symbol.metadata] nonconfigurable-nonwritable null.

Hmm, one thing I'm realizing here is that all classes get Symbol.metadata, I wonder if we should add the metadata object in cases where decorators are applied, so that it's more performant? If so, then nonconfigurable-nonwritable null would make more sense, otherwise we could do the Get conditional.

My intuition is that classes without any decorators don't have a metadata object. But we should probably talk about this in committee?

Yeah that was my original intention, but I just realized on reading that I hadn't made that part optional in the spec. We can discuss in committee.

bakkot · 2023-05-17T00:30:22Z

spec.html

@@ -30619,6 +30628,7 @@ <h1>Properties of the Function Prototype Object</h1>
        <li>does not have a *"prototype"* property.</li>
        <li>has a *"length"* property whose value is *+0*<sub>𝔽</sub>.</li>
        <li>has a *"name"* property whose value is the empty String.</li>
+        <li>has a @@metadata property whose value is *null*, which is non-writable and non-configurable to prevent tampering that could be used to globally add metadata to all classes.</li>


I think this should be its own section - we only really do "name" and "length" like this.

Compare, for example, GeneratorFunction.prototype [ @@toStringTag ]. (Except of course it should be non-configurable, and then it can be just "the value" rather than "the initial value".)

I'm neutral on whether to include the explanation in that section as well or just leave it out entirely.

Ah, I was looking for something similar and couldn't find it, I'll update!

bakkot

LGTM other than the lint failure and my comment (which does not need to block advancement).

bakkot · 2023-05-17T00:39:26Z

spec.html

@@ -24319,6 +24330,7 @@ <h1>
          _name_: a String, a Symbol, or a Private Name,
          _initializers_: a List of function objects,
          _decorationState_: a Record with a field [[Finished]] (a Boolean),
+          _metadataObj_: an Object or ~empty~,


This can't actually be ~empty~, can it? We only call this method if there are decorators.

That would be better handled by making this just "an Object" and adding an Assert: _metadataObj_ is not ~empty~ at the callsites.

Ah that's a good point, I can add conditionals there as well.

bakkot · 2023-05-17T17:14:42Z

spec.html

@@ -30724,6 +30755,13 @@ <h1>Function.prototype [ @@hasInstance ] ( _V_ )</h1>
        <p>This property is non-writable and non-configurable to prevent tampering that could be used to globally expose the target function of a bound function.</p>
        <p>The value of the *"name"* property of this method is *"[Symbol.hasInstance]"*.</p>
      </emu-clause>
+
+      <emu-clause id="sec-function.prototype-@@metadata">
+        <h1>Symbol.prototype [ @@metadata ]</h1>


Suggested change

<h1>Symbol.prototype [ @@metadata ]</h1>

<h1>Function.prototype [ @@metadata ]</h1>

bakkot · 2023-05-17T17:15:33Z

spec.html

+        <h1>Symbol.prototype [ @@metadata ]</h1>
+        <p>The initial value of the @@metadata property is *null*.</p>
+        <p>This property has the attributes { [[Writable]]: *false*, [[Enumerable]]: *false*, [[Configurable]]: *false* }.</p>
+        <p>This property is non-writable and non-configurable to prevent tampering that could be used to globally expose the target function of a bound function.</p>


Looks like a copy/paste error?

rbuckton · 2023-06-21T16:09:53Z

spec.html

@@ -25240,39 +25261,49 @@ <h1>
        1. Set the running execution context's LexicalEnvironment to _env_.
        1. Let _instanceExtraInitializers_ be a new empty List.
        1. Let _staticExtraInitializers_ be a new empty List.
+        1. Let _metadataObj_ be ~empty~.
+        1. If _hasDecorators_ is *true*, then
+          1. If |ClassHeritage?| is present, let _metadataParent_ be ? Get(_constructorParent_, @@metadata).


Not that class extends null {} actually works for construction, but won't this mean that @dec class extends null {} will throw?

If so, that seems better then doing what class extends null {} does (until we're able to fix extending null)

If that's the case, I'd maybe call it out in some sort of editorial note to indicate that the behavior is intended.

nicolo-ribaudo · 2023-08-25T14:21:26Z

spec.html

+        1. If _hasDecorators_ is *true*, then
+          1. If |ClassHeritage?| is present, let _metadataParent_ be ? Get(_constructorParent_, @@metadata).
+          1. Else, let _metadataParent_ be *null*.
+          1. Set _metadataObj_ to OrdinaryObjectCreate(_metadataParent_).


OrdinaryObjectCreate only accepts an object or null, but _constructorParent_[@@metadata] could be any ECMAScript value.

Probably we shuold:

if _constructorParent_[@@metadata] is undefined, fallback to null

if it's a different primitive, throw a TypeError

Or maybe always throw, given that there is the Function.prototype[Symbol.metadata] fallback and thus undefined must have been explicitly set.

Chris Garrett and others added 6 commits March 5, 2023 22:12

Non-normative fixes

1f42b91

Remove dynamic [[HomeObject]] from decorator return values

bcd170c

Throw an error if the value passed to addInitializer is not callable

a2b63dd

Set the name of the addInitializer function

5d556fe

Fixes based on feedback from @jmdyck

f604983

jridgewell mentioned this pull request Mar 22, 2023

March 2023 babel/proposals#87

Open

pzuraq and others added 7 commits April 12, 2023 04:27

Merge pull request #5 from pzuraq/remove-dynamic-home-object

e86128e

Remove dynamic [[HomeObject]] from decorator return values

Merge pull request #7 from pzuraq/throw-error-if-initializer-is-not-c…

ca35c74

…allable Throw an error if the value passed to `addInitializer` is not callable

Merge pull request #8 from pzuraq/set-add-initializer-function-name

444a531

Set the name of the `addInitializer` function

Call decorators with their natural this value.

50ce824

For more details, see this issue: tc39/proposal-decorators#487

Remove setFunctionName from decorator application

39e6e35

Merge pull request #11 from pzuraq/remove-set-function-name

43b16ea

Remove setFunctionName from decorator application

Merge pull request #6 from pzuraq/call-decorators-with-correct-this

823f1bf

Call decorators with the natural `this` value

bakkot reviewed Apr 26, 2023

View reviewed changes

pabloalmunia mentioned this pull request May 8, 2023

Support to stage 3 tc39/proposal-decorator-metadata#14

Open

syg reviewed May 10, 2023

View reviewed changes

pzuraq added 3 commits May 16, 2023 15:49

Reverse initializer order

c4465e4

Adds Decorator Metadata

ceb4225

Use null instead of Object.prototype as root metadata object prototype

90938f8

jridgewell mentioned this pull request May 16, 2023

May 2023 babel/proposals#88

Closed

Update spec based on feedback

fb0852e

pzuraq force-pushed the add-metadata branch from c8f04d7 to fb0852e Compare May 16, 2023 21:41

bakkot reviewed May 17, 2023

View reviewed changes

bakkot approved these changes May 17, 2023

View reviewed changes

bakkot reviewed May 17, 2023

View reviewed changes

more feedback

b5c0f4e

bakkot reviewed May 17, 2023

View reviewed changes

rbuckton reviewed Jun 21, 2023

View reviewed changes

nicolo-ribaudo reviewed Aug 25, 2023

View reviewed changes

rbuckton mentioned this pull request Dec 6, 2023

Add tests for Stage 3 Decorator Metadata tc39/test262#3971

Open

pzuraq force-pushed the decorators branch from 110f950 to 3f30554 Compare February 2, 2024 17:02

evanw mentioned this pull request May 12, 2024

Feature request: Implement the Decorator Metadata proposal evanw/esbuild#3760

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds Decorator Metadata #10

Adds Decorator Metadata #10

pzuraq commented Mar 7, 2023

bakkot Apr 26, 2023

pzuraq May 1, 2023

bakkot Apr 26, 2023

pzuraq May 1, 2023

syg May 10, 2023 •

edited

bakkot May 10, 2023

pzuraq May 10, 2023

syg May 10, 2023

pzuraq May 10, 2023

bakkot May 17, 2023

pzuraq May 17, 2023

bakkot left a comment •

edited

bakkot May 17, 2023

pzuraq May 17, 2023

bakkot May 17, 2023

bakkot May 17, 2023

rbuckton Jun 21, 2023

ljharb Jun 21, 2023

rbuckton Jun 21, 2023

nicolo-ribaudo Aug 25, 2023

nicolo-ribaudo Aug 25, 2023

	<h1>Symbol.prototype [ @@metadata ]</h1>
	<h1>Function.prototype [ @@metadata ]</h1>

Adds Decorator Metadata #10

Are you sure you want to change the base?

Adds Decorator Metadata #10

Conversation

pzuraq commented Mar 7, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

syg May 10, 2023 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bakkot left a comment • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

syg May 10, 2023 •

edited

bakkot left a comment •

edited