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

Composite types is not clearly defined #1076

Open
andimarek opened this issue Feb 11, 2024 · 1 comment · May be fixed by #1078
Open

Composite types is not clearly defined #1076

andimarek opened this issue Feb 11, 2024 · 1 comment · May be fixed by #1078

Comments

@andimarek
Copy link
Contributor

The spec uses the word "composite" 5 times, but it is never clearly defined.

While it is quite clear that composite for output types means Interface, Object or Union the usage for input types is in my experience much less common. The only input composite type is Input Object and the spec uses it in this way too.

We should clearly define the meaning of composite type.

@martinbonnin
Copy link
Contributor

+1 👍

Another option could be to just remove the "composite" term and be explicit instead? (i.e. use "object, interface or union")

Looks like the main place where the term is used in normative context is in field merging:

  1. If typeA or typeB is Scalar or Enum: ...
    a. If typeA and typeB are the same type return true, otherwise return false.
  2. Assert: typeA and typeB are both composite types.

That last sentence could be replaced by

  1. Assert: typeA is Object or Union or Interface and typeB is Object or Union or Interface.

It's more of a mouthful but the spec isn't really meant to be read out loud? :)

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

Successfully merging a pull request may close this issue.

2 participants