https://kotlinlang.org logo
Title
k

karelpeeters

08/31/2018, 10:21 AM
Nope nope nope!
2
👍 6
☝️ 4
p

pablisco

08/31/2018, 10:22 AM
Why? Why? Why?
d

diego-gomez-olvera

08/31/2018, 10:39 AM
every other project has a
StringUtils
or similar class
IMHO it is better for the developer (and the compiler) to easily know which class/function is being used
p

pablisco

08/31/2018, 10:42 AM
Maybe for the compiler, not sure about the developer... I can't remember the last time I looked at an import in Github or the IDE and said: "ah! that's what we are importing... nice."
l

louiscad

08/31/2018, 10:43 AM
Reproducible builds are important. I don't care having to scroll a bit for imports
👍 2
p

pablisco

08/31/2018, 10:45 AM
Why would it not be reproducible?
d

diego-gomez-olvera

08/31/2018, 10:45 AM
if a dependency is removed and another is added for a class or function, you would not be aware
nothing would change on the file
p

pablisco

08/31/2018, 10:46 AM
Which would make refactoring easier, right?
d

diego-gomez-olvera

08/31/2018, 10:47 AM
it would make the visual change smaller, yes
but also less explicit
p

pablisco

08/31/2018, 10:48 AM
Well, fewer places would require changes, not just visualy
d

diego-gomez-olvera

08/31/2018, 10:48 AM
the new class/function behavior could differ without the developer noticing initially
p

pablisco

08/31/2018, 10:50 AM
But that's the same if a library changes the behaviour of a specific type... not sure that's related with the imports
d

diego-gomez-olvera

08/31/2018, 10:51 AM
by having always imports for non stdlib code, the change will be shown in history
p

pablisco

08/31/2018, 10:53 AM
What I mean is that if the behaviour of a class changes and it's imported the developer will be oblivious to that change too
d

diego-gomez-olvera

08/31/2018, 10:53 AM
yes, but not to the fact that it changed
p

pablisco

08/31/2018, 10:54 AM
If the public API of that type has changed it'll be pretty obvious 😅
👍 1
d

diego-gomez-olvera

08/31/2018, 10:57 AM
simple example:
TextUtils.isGraphic
in Android does not check for
null
(nor is annotated). A 'pure Kotlin' project is converted to be an Android project, and its own version of the method (which checks for null) is dropped in favor of the Android one. It is used in rare scenarios not covered by tests.
I know that Kotlin has better solutions than that, it is just a made up example
the fact is that if the public signature does not change the developer will not be aware of the behavioral changes under the hood
p

pablisco

08/31/2018, 11:01 AM
In that scenario, the compiler would complain about ambiguity as it has two functions that have the same name and would have to do either an explicit import or do a typealias that changes the name of the function for that module
k

karelpeeters

08/31/2018, 11:12 AM
And then your build breaks because a dependency adds a new class somewhere.
Do you even spend time dealing with imports? I almost never touch them, I don't even see them, they are automatically hidden by the IDE.
1
s

Shawn

08/31/2018, 11:15 AM
nobody reads imports
they stay collapsed and honestly they’ve never added excessive “noise” to my PRs, this is a solution in search of a problem
👍 1
also the compiler would constantly complain about ambiguity - how many times have we seen someone ask in #general or #getting-started about some basic functionality not working as expected and it ending up being that they accidentally imported the wrong
TextView
or whatever?
do you use CI or have tests run automatically at some point? Do you want builds to start randomly failing because someone upped a version number and included a transitive dependency that exposes another
FooBuilder
or whatever and the compiler just now asks you to resolve the ambiguity?
What on earth would “module-wide import alias configuration” even look like? The name itself makes it sound an order of magnitude more complex and less portable than just qualifying your imports from the get go and letting IntelliJ handle the menial work
p

pablisco

08/31/2018, 1:08 PM
“module-wide import alias configuration” Would be useful on its own as then we don't have to do it on every file that uses that import. The main noise is on Github, like moving a file to a different package and then marking the PR to have 50 files changed and 100 lines changed for a simple refactor. Ideally Github could have more semantic diffs. Surely, saying that nobody reads imports is more of an argument for this feature.
Furthermore, packages are kind of an interop feature in Kotlin... There are way more versatile ways to limit scope (separation of concerns since there is no package private) of code in Kotlin than packages
g

gildor

09/02/2018, 8:39 AM
I would say that make sense to improve code review tools rather than change programming language and get all possible problems with implicit imports
1