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

Document standard library types #5431

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

Conversation

bentsherman
Copy link
Member

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 on toList().

Signed-off-by: Ben Sherman <bentshermann@gmail.com>
Copy link

netlify bot commented Oct 24, 2024

Deploy Preview for nextflow-docs-staging ready!

Name Link
🔨 Latest commit 2ae6c2c
🔍 Latest deploy log https://app.netlify.com/sites/nextflow-docs-staging/deploys/6734f2df88723300082bfa96
😎 Deploy Preview https://deploy-preview-5431--nextflow-docs-staging.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant