does the new recommended style of star-import ever...
# codingconventions
c
does the new recommended style of star-import everything cause problems for others as well? E.g. I was just now migrating an app to ktor 1.4 and kotlinx serialization 1.0-RC and wasted like 10 minutes trying to fix
Json {}
builder, until I noticed that intellij imported wrong class via star import before I got to Json {}. After this I'm reverting the style config, star imports are evil and when one wants them, this needs to be explicit. It was quite unexpected when JB introduced the convention. I did give it a chance, but nope,
import bla.bla.*
default was evil, is evil and probably will remain so while imports exist 🙂
☝️ 3
s
I generally call out wildcard imports wherever I see them; they’ve caused me a lot of trouble in the past with basically no tangible gain. I don’t think I’ve ever heard a compelling argument for them in JVM-land where imports are trivially handleable via the IDE
💯 3
m
I use star imports as recommended and they mostly work well. There are some cases though where either compiler or IDE make it more complicated than necessary. I guess that will improve over timer. Imports for extension functions are annoying in general. Same with companion objects. Error reporting of the compiler can be very misleading or confusing sometimes and makes it difficult to figure out potential import issues. Nonetheless I definitely prefer star imports over overly excessive imports that clutter my files and Git diffs. I'd still love to see a Kotlin without packages at all - just modules as in Swift 🙂
e
Indeed, there are some inconveniences that are migration-related.