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

What is the recommended approach for @ObsoleteCoroutinesApi #632

Closed
jcornaz opened this Issue Sep 28, 2018 · 6 comments

Comments

Projects
None yet
4 participants
@jcornaz
Copy link
Contributor

jcornaz commented Sep 28, 2018

Version 0.27.0 marked all channel operators with @ObsoleteCoroutinesApi saying:

This API has serious known flaws and will be replaced with a better alternative in the nearest releases.

My question here is: What is the recommended approach while waiting for the better alternative in the nearest releases?

Should we stop using channel operators?
Should we migrate existing code for an alternative technology (like RxJava) in the meantime?

@elizarov

This comment has been minimized.

Copy link
Collaborator

elizarov commented Sep 28, 2018

From the point of usage ObsoleteCoroutinesApi is just like experimental. The different is in intent. When API is experimental it might change or might graduate as is. For obsolete API we already know that there are problems with designs that will force us to deprecated this API in the future when we have a better replacement.

Right now there is no replacement for channel operations, so you have no choice but continue using them. However, we plan to replace them with mechanism based on lazy/cold streams (#254) in the future, which will get you much better performance.

@jcornaz

This comment has been minimized.

Copy link
Contributor Author

jcornaz commented Sep 28, 2018

Thanks @elizarov.

you have no choice but continue using them

One could use RxJava or any other reactive stream.

we plan to replace them with mechanism based on lazy/cold streams (#254) in the future

Will we get migration aid?

which will get you much better performance.

Glad to hear it. Even if I haven't been able to suffer any noticeable performance flaws so far.

@elizarov

This comment has been minimized.

Copy link
Collaborator

elizarov commented Sep 28, 2018

Obsolete is like experimental in this sense. There will be migration.

@matejdro

This comment has been minimized.

Copy link

matejdro commented Nov 2, 2018

I wonder how good an idea is to mark API as obsolete before offering any alternative?

This just forces anyone to put suppress warnings annotation everywhere when using the API. It's not like I can just stop using operators, apart from switching away from channels to RX (like jcornaz suggested), which I don't want.

@qwwdfsad

This comment has been minimized.

Copy link
Member

qwwdfsad commented Nov 5, 2018

I wonder how good an idea is to mark API as obsolete before offering any alternative?

KDoc to annotation literally says that this is the deprecated API which has no replacement or alternative.
The other options are @Deprecated (and a deprecation without replacement is even worse than experimental), and @Experimental which may give a false feeling that this API is good and may become stable in the future.

But I think we can improve documentation here. "Obsolete" means that you can still use it for a while, but it's better not to expose it to users (e.g. if you write some kind of a library or interop layer) or not to build your entire architecture on top of such primitive (e.g. actor)

@matejdro

This comment has been minimized.

Copy link

matejdro commented Nov 5, 2018

KDoc to annotation literally says that this is the deprecated API which has no replacement or alternative

I do realize that, but that still does not stop IntelliJ from painting my code yellow or compiler from spewing warnings for no reason as there is no alternative to using this apart from suppressing the warning which feels bad.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment