Define Data Collections used in the spec #1102
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
I think one logical consistent way to describe these data structures is with a minimal amount of predefined terms would be:
-
Everything is a collection. A collection is a finite group of elements that can be iterated over. The encounter order during iteration is not necessarily stable.
-
A List is a specific collection where each element can be accessed via a stable Integer >= 0, called index and the encounter order is stable. A List allows for duplicate elements.
-
A set is a specific collection where the elements are guaranteed to be unique. The encounter is not necessary stable ("unordered set"), but can be ("ordered set")
(If we need to define unordered set vs ordered) -
A Map is a specific collection of elements, where each element is a pair (called "entry") made of a key and a value. All keys are a set, while all values is just a collection.
The encounter order of a Map can be stable ("ordered Map") or not ("unordered Map")
(If we need to define unordered Map vs ordered)
|
Hopefully my latest edit factors in @andimarek and @martinbonnin's feedback. |
|
|
||
| ## Data Collections | ||
|
|
||
| A data collection is a finite, iterable aggregation of elements whose iteration |
There was a problem hiding this comment.
Why 'aggregation'?
- collection: tautology - "a data collection is a collection"
- set: we define "set" below, so using set here would introduce ambiguity
- group: evokes group theory, best avoided
- assembly: technically correct, but feels unnatural
There was a problem hiding this comment.
I removed this in editorial.
My thinking is that any reader of this spec does not need to learn what a data collection is in general (though fwiw, wikipedia does use the term "group").
What is important for us to clearly state is what aspects of that data collection is normative
leebyron
added
🏁 Accepted (RFC 3)
spec/GraphQL.md
Outdated
| implementations. Similarly, data collections such as _list_, _set_ and _map_ | ||
| also introduce conformance requirements. Implementers are free to use | ||
| alternative data collections as long as the perceived result remains equivalent. | ||
|
|
||
| See [Appendix A](#sec-Appendix-Notation-Conventions) for more details about the | ||
| definition of algorithms and other notational conventions used in this document. | ||
| definition of algorithms and other notational conventions used in this document, | ||
| and [Appendix A: Data Collections](#sec-Data-Collections) for specifics of data | ||
| collections and their ordering. |
There was a problem hiding this comment.
note to lee: simplify this addition a bit before merge
leebyron
force-pushed
the
data-collections
branch
3 times, most recently
from
57e8376 to
9b51301
Compare
leebyron
force-pushed
the
data-collections
branch
from
9b51301 to
68bc42a
Compare
github-project-automation
bot
moved this from Needs my work
to Done
in Benjie's GraphQL tasks
The spec uses the terms "set", "list" and "map" in many places. This PR defines these terms and their conformance requirements.
This is a change extracted from #1063 as discussed at last night's WG meeting
This is PR 1 of 3 in the "data collections" trilogy stack; next are:
cc @graphql/tsc
(Replacement of #1091; to do PR stack with #1092 and #1063)