https://kotlinlang.org logo
Join Slack
Powered by
I’m getting an error when trying to collect a flow...
# coroutines
s
I’m getting an error when trying to collect a flow. This seems odd:
Copy code
GlobalScope.launch {
    flow.collect {
    }
}
I’ve found other examples where a lambda works as a flow collector.
p
It happened to me the other day. It seems like the IDE is not passing the compiler the latest greatest version of the file. Maybe the file is out of sync. Refresh the IDE or cut the code and paste it again.
s
I’ve tried just about everything.
Even switched ides from android studio to IntelliJ Ultimate
l
You need to import the collect extension function.
➕ 1
d
Collect isn't an extension function I think
s
There are two versions of 
collect
, an instance method and an extension function. For your collecting code, you'll mostly use the extension function variation. That part was not well designed. And the (auto) import facility of the IDE doesn't help either....
➕ 1
e
Please, use start imports with Kotlin to avoid problems like that in the future.
l
star imports (i.e. 
import kotlinx.coroutines.*
, 
import kotlinx.coroutines.flow.*
)
s
On most team's code style guidelines that I've been working on, star imports are actively discouraged (usually auto-converted to regular ones)....
l
I personally prefer non star imports too, unless the packages are well known. The Android official style guide is no star imports BTW. Personally, I'd like an agreement between Google and JetBrains on which packages to allow star imports by default (packages from kotlinx.coroutines would be part of this).
d
I don't understand that star imports are actively encouraged to make working with official libraries easier. Star imports make it harder to reason about where a function is coming from. If the IDE came with default settings to automate this, that would indeed be better. But not everyone (as is evident) wants to use star imports. I suggest that extension functions are imported automatically alongside classes if they are declared on the same file, for a start - and then indicate the file as a class in Intellij so as to not discourage using extension functions.
👍 1
e
Star imports are not required, but really improve usability of Kotlin DSLs that are usually based on extension-centric design when most of helpful functions are not members, but extensions. No star imports policy indeed makes sense in Java, where a typical class that you import might have 100s of members you get all at once with one-line import, but it does not make a lot of sense in Kotlin where a typical package might have just a single class (e.g. 
Flow
) and 100s of extensions, each of which needs a separate import.
E.g., your Java 
import reactor.Flowable
actually corresponds to 
import flow.*
in Kotlin
d
It makes sense for the flow package, but it requires that I configure my IDE (requiring know-how) to always use * import for that package. By default, "optimizing imports" from the ide will replace it with normal imports again. Unless the defaults were changed and I never knew, the usability of this is quite lacking. Therefore, I think you will get this question over and over again. Following up on that, to import * feels like a workaround for a missing or incomplete language feature to me personally.
➕ 1
(The problematic part being that extensions from the same file / package as the type they extend need a separate import)
I want to add that I have a lot of respect for your work Roman, I think coroutines are very well designed, I just disagree with this interaction between the language and libraries and I hope we can make it better or clarify it by means of conversations like this.
e
It’s not just coroutines lib. All Kotlin libraries usally work better with star import. However, if you use a lot of Java in your project, you might not find that convenient. I wonder how we can improve it. Do you have any specific ideas?
d
Yeah, I suggested that extension functions from the same file or package (tbd) are imported alongside the type they extend. As an example (assuming it works on the whole package), if you import 
kotlinx.coroutines.flow.Flow
, You would get all extension functions of Flow (vast majority of operators). This makes sense because the extension functions are used as members of 
Flow
syntactically. Then you just need to import 
flow {}
or 
channelFlow {}
if you use one of those, which makes sense because they are not used as members.
I can put this on #language-proposals to expand the discussion
l
Oh yes, importing all the extensions from the same package of the imported type is a great idea that I think I'd enjoy having.
d
Perhaps it should work on modules rather than packages
That might be more complex to implement though
e
I don’t see how that’s much different from star imports.
s
I thought the jetbrains style guide prohibited * imports. If not the jetbrains style guide, the Android kotlin style guide definitely does. And tools like ktlint don’t have a way that I know of to override them. APIs requiring star imports to be usable seems like an obvious anti-pattern.
l
In application code (not library), you'd not get everything imported, but only the extensions for the same package as the type. That'd make the code more understandable. Remember than many people, including me, are reading Kotlin code in a browser without cloning the whole project and waiting for Gradle sync and IDE indexing. Than means no cmd/ctrl hovering info. Same when code is read on mobile. I dislike star imports on all the code because of how negatively it impacts readability where new libraries or packages are used. That's why I'd like to have them only on exceptions like Kotlin flows, and I think the language should help library developers like you add this. I'm not sure such a tool should be given to everyone though, or if it is, it should be opt-in, maybe with the exception of select kotlinx and androidx libraries.
e
Kotlin, the language, and its libraries are designed with start imports in mind. If standard library weren’t imported by default, you’d have the same issue with it. Any Kotlin DSL would look ugly without star import. However, indeed, when you work with Android, which is mostly Java, you should prefer Java-style single-class import, since in Java a class is usually a single unit of an API. In Kotlin a single unit of API is usually a package. I can only think of solution that would somehow distinguish Kotlin/Java packages or classes and make imports individual or star depending on that.
That’s the overall idea I have in mind https://youtrack.jetbrains.com/issue/KT-34230
👍 1
s
I like the idea. This would require not only a change in the IDEA (put intended), but would need some serious publicizing to the larger dev community as well (to change their Lint rules, review/PR practices, regarding star-imports).
e
@streetsofboston This realization should come gradually as people move from using Java-centric APIs (where every API is a class) to to Kotlin-centric APIs where top-level functions rule and a typical API is a package.
s
@jw ^^ If star imports are important from @elizarov’s perspective, I think it’s important to get alignment in the Android coding styles so the code style checkers can be updated as well. Currently the Android style guide doesn’t allow wildcard imports.
j
It's extremely unlikely to be changed. Star imports are for people who use text editors. They're not needed in a world of IDEs and Kotlin is not usable without an IDE.
I also find default package imports to be more annoying than useful. They cause all kinds of problem with code generation. Again, something that's great for text editors but whose utility is entirely obviated by an IDE.
s
@elizarov ^^ this makes things difficult from my perspective then. To be fair, I’ve been using Kotlin as my primary language for 3 years now. This is the first time I’ve had a problem specific to star imports.
e
Just because stdlib is auto-imported. We can “solve” it by having coroutines and flow auto-imported, too, but I don’t like this kind of “solution” (it does not scale to be big Kotlin libraries ecosystem)
Imagine stdlib was not imported. You’d have to press Alt+Enter each time you do 
filter
and any other trivial operation.
Imagine, for a moment, if in Java you’d have to import every individual method you use.
j
But that's already the behavior with 99% of the code I work with since it's not the stdlib.
Same is true of types. Every time I write "Flow" i have to alt+enter to import it.
I rarely get beyond three letters into a type or extension name before i'm hitting enter, getting the automatic import, and moving on
e
No star imports policy makes Kotlin programming experience less fluent than Java one. In Java a unit of API is typically a class. You import it once to say “I’m using this API here” and you’re done. In Kotlin a unit of API is often a package. With star imports in Kotlin you also import it once to say “I’m using this API here”. That’s why in Kotlin libraries team we have “star imports” policy.
j
I think that conjecture lacks proof
e
Which conjecture? The one about Java vs Kotlin fluency or the one about Java vs Kotlin API design style?
d
There's not necessarily one kotlin api design style
But the one with many extensions in a package is common
The star import makes sense for those, but it sounds like there is significant resistance in generally permitting star imports
Therefore my suggestion becomes relevant again (at first I thought your approach would make it unnecessary/obsolete)
What do you think of that one @jw? It's a few messages up in the thread
j
Quantity of imports doesn't make a difference since the IDE manages them all.
I'm also not convinced by the argument that a star import is a signal that you're using an API since you can encounter types through other APIs without an import. I can run into a 
Flow
from my own repository type and want to collect it in a new file with no imports for the package. Assuming that a star import will be present already for the flow package means this consumption case is broken. Of course, it's not actually broken since the IDE handles it fine and emits the correct 
collect
import if you let it.
👍 2
s
That was actually the problem. I was finding that the IDE wasn’t offering the 
collect
import. Perhaps that’s where this can be addressed. What I was hearing from @elizarov was that the only way it will work naturally is with wildcard imports.
5 Views
Open in Slack
PreviousNext
Powered by