Importing multiple entries in a single line

Here is a code example:

import com.my.package.util.fun1
import com.my.package.util.fun2
import com.my.package.util.fun3
import com.my.package.util.fun4
import com.my.package.util.fun5
import com.my.package.util.fun6
import com.my.package.util.fun7

Why not to remove repeating characters like this:

import {fun1, fun2, fun3, fun4, fun5, fun6, fun7} from com.my.package.util

This syntax is used in ES6/TypeScript and looks very compact and readable.

1 Like

You can use import com.my.package.util.*

BTW, these import is supported from the IDE. I don’t see any problem when we import each package individually

There are some people in this world that just like using Notepad :slight_smile:

1 Like

Our position is that, if you’re doing anything with imports manually, you’re doing it wrong. The correct way to deal with imports is to use auto-import and “optimize imports on the fly” features in the IDE. Because of that, making imports compact and readable is a non-goal - you’re not supposed to ever read them.

7 Likes

Statements like this put JetBrains at real risk of disenfranchising programmers (including myself) who prefer to program outside of a rich IDE.

Just use wildcard imports. That’s what I usually do. You run into conflicts so infrequently that it’s not worth worrying about until you do and then most of the time a simple alias will fix the problem. I don’t get why this isn’t the default anyways

2 Likes

Appreciate it!

The common Kotlin code cannot be read without an IDE anyway. There are so many context switches through extension functions that you often cannot see in the code where a called function is coming from.

I don’t mean this in a negative way. I strongly believe that the future of programming will rely heavily on IDEs and I hope Kotlin will go further into this direction.

5 Likes

Fair points, thanks for sharing that.

Certainly believe in a rich IDE being necessarily idiomatic for Kotlin. In addition, remaining accessible to vim/emacs/notepad development seems vital to it one day overtaking Java as the general-purpose JVM language of choice.

I can’t believe I just read that from somebody from JetBrains team. That’s an unfortunate answer.

1 Like

Positions may change, right? :grin::sweat_smile::neutral_face:

I think there’s potential here for a more delightful developer experience for newer developers in particular—new to Kotlin, and new to the entire Java ecosystem. Figuring out “where stuff is declared” has typically been a challenge for me personally, especially when I began picking up Rust (and now I’m picking up Kotlin).

It would be nice to have a syntax like Rust’s use declarations

use std::option::Option::{Some, None};
use std::collections::hash_map::{self, HashMap};

… or ES6 imports…

import { useEffect, useState } from "react";

Reasoning is:

  • I have no idea what’s inside:
import io.javalin.*
  • But this is clear as to what is being pulled into my current file
import io.javalin.Javalin
import io.javalin.apibuilder.ApiBuilder.get
import io.javalin.apibuilder.ApiBuilder.post
  • And [potentially] then this would be compact
import io.javalin.{Javalin, apiBuilder.ApiBuilder.{get, post}}

…maybe that looks silly. :joy:

Just my 2 cents.

So as far as I understand it, the request is motivated by at least two things:
1) I want to see all imports (to know where things come from and what’s being used)
2) I want the import statement to be compact

Personally, I don’t mind if the import statements aren’t compact but instead if it’s readable and easy to see what is being used. So I’d add #3 as “I want the import statement to be readable”.

IMO, all of these cases are covered by the current system.
If you want compact import statements (#2) then wildcard is available.
If you want to see all of the imports (#1), you can write them out per line.

But for making the import statement readable (#3), I find the line-per import much more readable than ES6 style. Here’s the two for comparison (same example shown in your post:

import io.javalin.{Javalin, apiBuilder.ApiBuilder.{get, post}}
import io.javalin.Javalin
import io.javalin.apibuilder.ApiBuilder.get
import io.javalin.apibuilder.ApiBuilder.post

For very few imports it’s easy to see what is included in the ES6 style. But once you get a longer list of imports, being able to easily scan a sorted and column aligned list is much quicker for me. I don’t have to scan every line for nested lists of lists like the ES6 example.


Maybe I’m missing some of the advantages of ES6 style imports, or maybe there’s a third style that is even better–Still, even if it turns out to be better to use ES6 style, I suspect the gains may not be worth enough to get past the minus 100 point rule.

The current system is not a widespread or a high impact pain point.

EDIT:
The Kotlin/Java ecosystem is deeeeeply tooled–to the point where you might go months or years without manually typing or deleting an import statement. The IDE makes import management and insight so effortless that some of us have forgotten import statements even exist :stuck_out_tongue_winking_eye:

6 Likes