One idea I wanted to follow up from the above thread: https://nfcore.slack.com/archives/C07ACNLELR2/p1792102821217429 Jim briefly mentioned his idea about calling processes like functions. Now that everyone has the relevant context fresh in their minds, I thought it might be worth asking about this again. To be clear, this is what he's talking about:

ch_samples.map { r ->
    BWA_MEM(
        id: r.id,
        reads: r.reads,
        bwa_index: r.reference,
        args: "--my-arg",
        args2: r.single_end ? "--single-end" : ""
    )
}

In fact, I considered this approach for 26.04, but ultimately dropped it out of concern that it would "obscure" the process calls in the workflow logic. Most people think of nextflow as "processes connected by channels", and this approach kinda inverts that mental model But I think Jim is correct that this is likely the "cleanest" way to deal with naming conventions and adapter logic What do you think about this at a glance? I don't think it's a blocker for migration, but it is one of those "nextflow features" we could add to ease the pain. Just some food for thought

👀 I kind of like this

I obviously would really like this 😂 There would be considerations to make about input structures, assuming both methods are supported (single record input vs. many flat inputs), but I think it would be doable. Things I like about this: • separation of concerns about names • you get access to the input channel and the output channel /in the same context/. So you can join them together and do what you like without having to finagle a join later using metadata.

Me too!

I liked that idea in the previous dsl3 branch you made. It is a change in thinking, but I think it helps in the long run. I guess that

map

would then also include any input change operations too which would keep it together

• you get access to the input channel and the output channel /in the same context/. So you can join them together and do what you like without having to finagle a join later using metadata.

And because of this, I think it might also reduce the necessity of a

meta

object and allow easier use of flat records