Document standard library types #5431
Draft
+770
−236
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is an initial attempt to flesh out the reference docs for standard types like lists, maps, sets, and strings. These types are used often in Nextflow, but users have difficulty using their APIs because we mostly delegate to the Groovy docs for these things.
Some notes:
The full set of Groovy/Java APIs is HUGE, but most of them aren't needed in Nextflow or are redundant. I have tried to pick out a minimal set of types and methods that cover most use cases. We can always add more things, but every new thing should be justified.
For now I'm just using Java types exactly as they are called. I doubt we'll have the exact same type nomenclature, but I think it will be similar enough that we can evolve it from Java as a starting point.
Many of the Groovy APIs are not fully typed, especially with generics (e.g. list element type, map key/value types, closure param/return types). The Java APIs are (mostly) fully typed but I haven't bothered with generic types yet (e.g. for List / Map / Set) because it would just get ugly. I think this is fine for now, we can revisit when we build out the statically typed std lib.
On that note, we'll likely want to swap out some Groovy APIs with our own implementations that are fully typed. This goes back to my first point about only taking what we need from the Groovy APIs.
I really don't want to expose type hierarchies in Nextflow, but I have made one exception here for "Iterable", because there are three types of collections (Bag, List, Set) and they have mostly the same methods with some small variations. So it's easier to expose Iterable as a sort of shared interface or trait. I think this is fine, we'll need it anyway for things like
flatMap(splitCsv)
I have taken care to not add APIs that can lead to non-deterministic behavior (e.g. getting the "first" element of a set). Any collection methods that rely on order are only documented for List, and any unordered collection must go through
Iterable::toList()
to access these "ordered" methods. Note the big fat "danger" notice ontoList()
.