I find `Flow` very well designed, kudos to the peo...

# coroutines

[louiscad]

I find Flow very well designed, kudos to the people involved.
I like how it reuses the continuation of the consumer and how exceptions and cancellation are propagated.
Is it bad to use them in production under their preview status? 👌 or 🚫

[elizarov]

Thanks. We have a lot of hindsight in our design and a great community that helps with feedback. As for status… what if we, for example, change the package from kotlinx.coroutines.flow to kotlinx.coroutines.flows when they go out of preview?

[louiscad]

Then, I do cmd+shift+R (Replace in Path) on all the libraries and projects that depend on it.

I've started to integrate Flow in a library, but I didn't release a version yet (other than a dev version), and that library is still in alpha anyway, because I'm cautious about the possible API changes or removals, especially with a little AndroidX overlap (from the latest alphas).

[louiscad]

BTW, I did a package rename in the past on a public library, and I wish library artifacts could bundle IDE actions for code refactoring, like renaming packages, classes, and patterns, that otherwise all library consumers have to do by hand for each replace needed. This could be metadata to allow fully automatic or step-by-step semi-automatic migrations, bundled in META-INF, or alike.

Is that something you've thought about? I've had quite a few ideas on how to make the experience for both library developers and consumers. That might be the next step after Deprecated ReplaceWith and experimental annotation comments.

[littlelightcz]

@louiscad If your codebase is rather small, then you probably don't need to worry about the PROD that much 🙂

[louiscad]

@littlelightcz Sorry, what is "PROD"?

[littlelightcz]

we use it as a shortcut for "production" here simple smile

[littlelightcz]

you know ... corporate world 😉 😄

[louiscad]

I see why you want to rename the package from flow to `flows`: consistency with channels and selects.

[elizarov]

Nobody seem to like the flows name, though, so far it looks like it stays as flow despite inconsistency.

[louiscad]

One of the reasons may be because of spelling, which many do internally while reading, as flows is more mouthful than flow. Still, I don't think it's so important as imports are usually added by the IDE.

For testing on kotl.in, play.kotl.in or try.kotl.in, flows may be more natural to star import alongside coroutines, channels and selects, so the renaming might make sense for this use case.

When you say nobody, do you include yourself?

[elizarov]

I have not decided 🙂