CreateMethodProperty vs CreateNonEnumerableDataPropertyOrThrow

[bathos]

These two AOs have identical steps & assertions / implement identical behavior. The only difference (apart from their names) seems to be how their explanatory notes describe the descriptor field pattern:

CMP

[...] same defaults used for built-in methods and methods defined using class declaration syntax

CNEDPOT

[...] same defaults used for properties created by the ECMAScript language assignment operator except it is not enumerable

...but AFAICT, even if those bits were swapped it wouldn’t seem to make anything less/more clear — “same as assignment operator except not enumerable” is just another way of saying “same as used for built-in/class-syntax methods” and vice versa, right?

My best guess is that maybe they materially differed prior to an editorial update and that the continued existence of both might just be something leftover from that (hinted at by the fact that CreateNonEnumerableDataPropertyOrThrow can never throw!) — but I’m not sure. Is there a reason for both of these seemingly-synonymous AOs to exist rather than just one?

[ljharb]

Can’t it throw on a frozen or sealed object?

[bathos]

Can’t it throw on a frozen or sealed object?

The first step of both is this assertion:

1. Assert: O is an ordinary, extensible object with no non-configurable properties.

(All four steps for both are char-for-char identical, including the ! before DefineOwnPropertyOrThrow.)

The notes for both also end with these two sentences:

Normally, the property will not already exist. If it does exist, DefinePropertyOrThrow is guaranteed to complete normally.

Their names and the explanatory text I quoted are the only places they differ.

[ljharb]

Gotcha, fair enough.

I think the OrThrow suffix is very useful, even if it can't throw, because there's other AOs where Foo returns a boolean, and FooOrThrow returns a normal or abrupt completion, and thus you can safely ? or ! the result.

It would make perfect sense to me to have CreateMethodProperty use CreateNonEnumerableDataPropertyOrThrow if that's doable, but in general it's useful for the name of an API to tell you its purpose, not its implementation, and "CreateMethodProperty" much more clearly describes what it's doing than CreateNonEnumerableDataPropertyOrThrow.

[jmdyck]

When PR #2356 (merged 2021-11-04) introduced CreateNonEnumerableDataPropertyOrThrow, it was slightly different from CreateMethodProperty.

Then PR #2759 (merged 2022-08-10) changed CreateMethodProperty with the effect (though not the intent?) of making it the same as CreateNonEnumerableDataPropertyOrThrow.

[michaelficarra]

Result from editor call today was that we will get rid of CreateMethodProperty (it only has one call site) and rename CreateNonEnumerableDataPropertyOrThrow to something more appropriate.