Imports

Language Design
1

Here are two suggestions for imports.

1) It would be really cool to be have named package imports:

import com.pkg.whatever as whatev
...
val x = whatev.somePackageLevelFunction()

You can already do that with objects, but sometimes you don’t want to group your function within objects and have to use import com.pkg.whatever.WrapperObject.* a lot internally. Especially since auto-completion does not kick in.

2) Extension methods could use some import-level support.

It’s not rare that I want to import all extensions to a type X from a certain package. But I can’t do that, you either import everything (import com.pkg.*) or you must import your extension methods one by one.

You could put all extensions methods in a separate package (and it’s really nice that you don’t need to put them in a separate folder!), but again, internally you’ll need to use import com.pkg.xextensions.* a lot).

It could look something like this:

import com.pkg.(X) // import all extension methods for X defined in `com.pkg`
8 Likes
2

Aliases for packages

First paragraph look like very useful feature for developers how like write functional code.

1440×900 79.4 KB

For example, in big program clash on function signatures it’s very possible event.
In Clojure it solved by namespaces, but in Kotlin we has nothing (see below).

Alternatives:

  • “Object/Component object” - restrice to hold all functions in one file and have bad syntax
  • Hack with annotaion (see code) - even more strage syntax and not supports on JS/Native
@file:JvmName("Func")
fun's ....

//usage
typealias f = Func
f.fun1

In my case it’s will be the best to write something like:

import org.app.domain as d
import org.app.presenter as p

fun main (args: Array<String>) {
    d.func1()
    d.func2()
    p.func1()
    p.func2()
}

Maybe someone create proposal for KEEP?

3

I don’t have the time to write one right now, but if someone does, I’m willing to review it.

4

By the way Scala has package aliases:

import java.util.{concurrent => c}

val future = new c.CompletableFuture

If Kotlin wants to be best multi paradigm (FP) language, it’s +1 reason for aliases.

5

I agree that current mechanism where you can import function as with name change is pretty wired:/ and I would prefer import some package and name it

Currently it looks this way:

import func1.doSth as f1
import func2.doSth as f2

fun main(args: Array<String>) {
    f1()
    f2()
}

And when I am naming the function then I am doing it for reason. I don’t want anyone to use it with a different name. It is really confusing. In case of name conflict, I would prefer to prefix function with some name that will tell which function is that.

6

I think it’s already supported:

import java.math.BigInteger as BigInt

fun main(args: Array<String>) {
	val a = BigInt("233")
	println(a + BigInt("666"))
}

When you’re confronted with some problems, RTFM first :smile:

7

Named imports are possible for classes, not for packages.
Understand The Fucking Post first?

8

Well, I apologize for my carelessness.
And I don’t have any idea about named imports for packages. :joy:

—Original—

1 Like
9

In C# this is possible:

using Project = PC.MyCompany.Project;

This would be great for different packages that have simular class names.
It makes the code easier to read.

Foo.MyNiceClass
Bar.MyNicerClass
1 Like
10

ping.
Any progress with that? I consider switching from dependency injection to a functional approach but having to use global functions without an indication where does it comes from is not an option.

1 Like
11

Is there anything you want to do that import .. as .. doesn’t do? It works on classes as well as functions.

12

I would really like to see named imports for packages like this. This is particularly useful when working with integrations where it’s very likely to have class names duplicated between an external API, DTOs, and an internal API. I often need to do conversions between classes or abstract api responses and requests in a consistent way that makes it cumbersome to manage the individual imports.

In these cases, it would be great to import the package with a short alias and be able to refer to them as in the following example:

import com.vendor.client as vendor
import com.us.api.*

// ...
val ourAddress = Address()
val vendorAddress = vendor.Address()
// ...
1 Like
13

That’s awesome that scala has this feature. I do hope we can get this in kotlin without the curly brace and arrow syntax sugar though. I’m curious…is there something that syntax allows that couldn’t be handled effectively with the as keyword.