-
Notifications
You must be signed in to change notification settings - Fork 664
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
base: master
Are you sure you want to change the base?
Conversation
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>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
@pditommaso @ewels this PR is a first iteration to document the "standard library" for Nextflow, so that people don't have to go digging through the Groovy docs to figure out how to use things like lists, maps, strings, etc Would like to get this merged soon. I have documented methods that I feel confident should be part of the standard library, and we can always document more as needed |
Co-authored-by: Chris Hakkaart <chris.hakkaart@seqera.io> Signed-off-by: Ben Sherman <bentshermann@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Language looks good. The stdlib page is very long and it would be good to split it up, but we can leave that for another PR.
5a93547
to
27345a6
Compare
@ewels do these docs make sense to you from a user perspective? |
Signed-off-by: Ben Sherman <bentshermann@gmail.com>
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()
.