Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: replace Type(...) notation with a proper Type AO #3339

Closed
wants to merge 3 commits into from

Conversation

michaelficarra
Copy link
Member

Fixes #2870. This aligns with our goal of reducing our core concepts.

  1. I believe this is the last place where we reified ECMAScript language types.
  2. Fewer special forms and macros, more AOs.

spec.html Outdated Show resolved Hide resolved
spec.html Show resolved Hide resolved

<emu-clause id="sec-ecmascript-language-types">
<h1>ECMAScript Language Types</h1>
<p>An <dfn variants="ECMAScript language types">ECMAScript language type</dfn> corresponds to values that are directly manipulated by an ECMAScript programmer using the ECMAScript language. The ECMAScript language types are Undefined, Null, Boolean, String, Symbol, Number, BigInt, and Object. An <dfn variants="ECMAScript language values">ECMAScript language value</dfn> is a value that is characterized by an ECMAScript language type.</p>

<emu-clause id="sec-type-ao" type="abstract operation">
<h1>
Type (
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking this AO would be better placed in section 7 "Abstract Operations". (Note that its first use occurs in 7.2.9.) Now I'm less sure, but I thought I'd mention it anyway.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I like it here. Section 7 AOs should probably be dispersed to relevant sections.

@michaelficarra
Copy link
Member Author

Feedback addressed.

@michaelficarra
Copy link
Member Author

https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal will need to be updated (and possibly others).

@michaelficarra michaelficarra added the editor call to be discussed in the next editor call label Aug 26, 2024
@syg
Copy link
Contributor

syg commented Aug 28, 2024

Recapping editor call discussion:

Let's hold off on this as @ljharb may have cycles to do the following to get us to the desired end-state of not having any type reflection at all:

  1. Introduce a SameType() AO
  2. Replace the CreateArrayFromList type list with a 2-state enum for all types and property keys only
  3. Do something else for the BigInt dispatch table, either splitting 2 tables or using a difference phrase

@ljharb
Copy link
Member

ljharb commented Aug 28, 2024

See #3408 and #3409 for 1 and 2.

@ljharb
Copy link
Member

ljharb commented Sep 6, 2024

#3410 and #3420

@ljharb ljharb closed this in #3420 Sep 23, 2024
@bakkot bakkot removed the editor call to be discussed in the next editor call label Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

make Type(...) macro an AO and return a spec enum
5 participants