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

<dfn> IteratorResult object #3426

Closed
michaelficarra opened this issue Sep 18, 2024 · 5 comments · Fixed by #3459
Closed

<dfn> IteratorResult object #3426

michaelficarra opened this issue Sep 18, 2024 · 5 comments · Fixed by #3459

Comments

@michaelficarra
Copy link
Member

We use IteratorResult object as if it's a defined term but I was surprised to learn that it doesn't actually have a <dfn>. We also have some references to it as "the IteratorResult interface", including the place where I think it should be defined. We should add the <dfn> and replace the "interface" references.

@jmdyck
Copy link
Collaborator

jmdyck commented Sep 19, 2024

I agree to linking back to the definition, but why replace the "interface" references? Are you saying it shouldn't be an interface?

What about the other iteration interfaces? Note that most of them also have corresponding occurrences of "a /Foo/ object". Should the spec drop the idea of interfaces altogether?

@michaelficarra
Copy link
Member Author

I think any definition of an "X object" is a description of its interface. I don't see a reason to use the term "X interface" instead of just saying "X objects".

@bakkot
Copy link
Contributor

bakkot commented Sep 19, 2024

Saying something is a Proxy object does not just describe its interface.

@michaelficarra
Copy link
Member Author

michaelficarra commented Sep 19, 2024

When it's defined by its interface (as with IteratorResult), yes it does. Saying "an IteratorResult object" is the same as saying "an Object that obeys the IteratorResult interface". There's just no need for the verbose latter form.

@jmdyck
Copy link
Collaborator

jmdyck commented Sep 19, 2024

When describing exotic objects, "an X object" means an object whose internal methods conform to the requirements specified for X objects. But when Y is an interface name, "a Y object" means an object that has properties that conform to the interface definition.

While you can define things that way, I wonder if it's confusing for readers (and if leaning into the latter usage would make things more confusing).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants