-
Notifications
You must be signed in to change notification settings - Fork 651
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
Document standard library types #5431
Draft
bentsherman
wants to merge
9
commits into
master
Choose a base branch
from
docs-standard-library
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
✅ Deploy Preview for nextflow-docs-staging ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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()
.