Are there any downsides to using `import packageWi...

# announcements

[benleggiero]

Are there any downsides to using import packageWithWayTooMuchInside.*?

[louiscad]

It may make understanding where this and that symbol or operator, used in the file, comes from, harder. I assume that's why the Android Kotlin style guide discourages * imports.

[igor.wojda]

In general this is considered bad practice. It may might shadow some other object from previous import and you won’t know about it
. Also you don’t know exactly what is imported and might not been able to find place from what module certain thing was imported easily

[Olekss]

To contrary. It is good practice.
Only reason to use specified name is to resolve conflicts if you have some.
Because it is st00pid to have 2 pages of imports which then you ask your IDE to "clump" into nothingness. But with this approach you can see directly which packages you are dealing with.
Conflicts of naming/shadowing current IDEs will show you.
And no you are not holding whole package in the memory, you load only actually used (and referenced) classes

[igor.wojda]

@Olekss Personally I use IDE auto-import and mostly forget about dealing with imports, but I am curious - what advantages (of using whole packages instead of specific entities) do you have?

[adams2]

the previous default style would often decide to import java.util.* and it was kinda annoying

[benleggiero]

Thanks for y’all’s input!

[Joshua F]

I'd say it's useful for some stuff, example being importing all elements in an enum so you don't have to prefix them with EnumName

[Joshua F]

I typically try to avoid * though

[benleggiero]

I was a little miffed when I found out that Swift forces this on you… then I realized that if there’s any ambiguity, it’s easy enough to just use the fully-qualified name, especially when the packages aren’t too deep. That’s why I ask; I was thinking about implementing this pattern in my projects

[Olekss]

@igor.wojda
I don't use the package, I declare the package...

[Olekss]

So from code size/compilation etc. there is no difference. You don't get + or - on the final code depending on how you declare it.
BUT... when I have on the top of my class 2-3 packages imports declared instead of 20-30 lines of particular imports I can easely deduce what are the package dependencies for my class
It is much easier to think about refactoring, it is easier to understand what am I dealing with.
I would suggest Ucle Bob Martin or Kevlin Henney videos where they speak about these matters.