Use Channel instead of channel

[bentsherman]

DSL2 introduced channel as an alias for Channel to create channel factories. I assume this was for consistency with other lower-case words like "process" and "workflow". However, Channel is a type like List or Map or Path, and the channel factories are static methods that create values of type Channel.

Technically, channels in Nextflow are of type DataflowReadChannel, but this is really an implementation detail. When we implement static types, we can provide an explicit Channel type to the user that does not expose such internal details To prepare for that, we should deprecate the use of channel before it gets any more widespread and causes confusion

[netlify]

✅ Deploy Preview for nextflow-docs-staging ready!

Name	Link
🔨 Latest commit	302b7b5
🔍 Latest deploy log	https://app.netlify.com/sites/nextflow-docs-staging/deploys/66fd7acff9034d000988f5bd
😎 Deploy Preview	https://deploy-preview-5352--nextflow-docs-staging.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ewels]

Do we want to completely remove reference to this? It's out there in the wild already..

[bentsherman]

we could take it or leave it. the strict parser will recognize it and give a deprecation warning

[christopher-hakkaart]

I agree with Phil here that it's already out in the wild and will cause frustration if it's not documented why.

Maybe:

channel was introduced as an alias of Channel, allowing factory methods to be specified as channel.of() or Channel.of(), and so on. It is preferable to use Channel to maintain clarity and follow best practices. channel will be depreciated in the future.

Or something like that.

[pditommaso]

Why this? actually the plane was to converge to channel.x over Channel.x

[bentsherman]

actually the plan was to converge to channel.x over Channel.x

why?

[pditommaso]

because the use of uppercase is a legacy of Java conventions, but there's no really reason in nextflow lang. I always found unnatural the need to capitalise channel

[bentsherman]

Uppercase is still needed to distinguish types from variable names. Otherwise it's difficult to tell which is which at a glance. This is not so important now but will become important when we add static types. So we need to prepare now

[pditommaso]

Uppercase for types is a pure convention, above all as a nextflow developer I should not be exposed to Channel as type, that's an implementation details. It can be seen as an implicit variable or namespace identifier to access factory methods

[bentsherman]

Users absolutely will be exposed to Channel as a type when we start supporting static types:

workflow foo {
  take:
  inputs: Channel<Path>
  param1: String
  param2: Integer
  flag1: Boolean

  main:
  // ...
}

Similarly when hovering over a variable, they will see something like Channel<T> in the tooltip

Therefore it makes most sense for the channel factories to be static methods of the Channel type, to make it clear that you are creating a channel

[bentsherman]

Of course I agree that we shouldn't expose DataflowReadChannel / DataflowWriteChannel, as they provide many methods that aren't meant to be used like reading/writing individual items and GPars operators like chainWith

With static types, Channel would essentially be a handle that is passed around between factories and operators