You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Nextflow currently supports both the filter and map operators against a queue channel. It is very common to combine these, so it may be useful -- as a convenience -- to have a single filterMap operator that does both operations.
The above may not look like much of an improvement, but bear in mind that it's maximally generalised. Maybe an outer join would be a more realistic example:
// Channel of the keys in myChannelA that are not in myChannelB// NOTE For sake of the example:// * myChannelA emits [ meta ]// * myChannelB emits [ meta, etc ] and is *not* empty
myChannelA
| join(myChannelB, remainder: true)
| filterMap { meta, etc -> etc ?null: meta }
Suggest implementation
I've modelled this on Rust's std::iter::Iterator::filter_map, in which its closure returns an Option<T>: if it's Some<T>, then that's the matched and mapped value (of type T); if it's None, then the filter skips. Groovy/Java (AFAIK) doesn't have an equivalent of Option<T>, so I've gone with not-null and null, respectively (presuming it's unrealistic for the mapping function to return null).
The text was updated successfully, but these errors were encountered:
The only thing is, as I've been investigating how to evolve the Nextflow language, I feel that operators are over-used, because they are often needed to fill gaps in the language. So I want to find ways to fill those gaps and make operators less necessary first, before we keep adding convenience operators and potentially further enable bad patterns. For example, I think we can make it so that branch and multiMap are not needed compared to filter and map.
That being said, I've also found filter_map to be useful in Rust, and it seems like a valuable enough convenience even if we manage to simplify the library and usage of operators. I definitely prefer it over branch
New feature:
filterMap
operatorNextflow currently supports both the
filter
andmap
operators against a queue channel. It is very common to combine these, so it may be useful -- as a convenience -- to have a singlefilterMap
operator that does both operations.Usage scenario
Before:
myChannel | filter { someCriteria(it) } | map { someMap(it) } | // etc...
After:
The above may not look like much of an improvement, but bear in mind that it's maximally generalised. Maybe an outer join would be a more realistic example:
Suggest implementation
I've modelled this on Rust's
std::iter::Iterator::filter_map
, in which its closure returns anOption<T>
: if it'sSome<T>
, then that's the matched and mapped value (of typeT
); if it'sNone
, then the filter skips. Groovy/Java (AFAIK) doesn't have an equivalent ofOption<T>
, so I've gone with not-null
andnull
, respectively (presuming it's unrealistic for the mapping function to returnnull
).The text was updated successfully, but these errors were encountered: