Hi. I'm not good at English but I made up a note a...

# language-proposals

[wcaokaze]

Hi. I'm not good at English but I made up a note about my proposal. Please read it
https://github.com/wcaokaze/KEEP/blob/root-packages-and-package-unit-imports/proposals/root-packages-and-package-unit-imports.md

[benleggiero]

If package foo.bar.baz implicitly invents the package foo.bar.baz and places this file in it, then why not make module Baz do the same thing? Why require a build system or compiler flag?

[benleggiero]

I don't understand why import ModuleName : packagename needs to be there. Why not just import packagename? Why must both be specified?

[wcaokaze]

It means import from another module.

[wcaokaze]

module Baz is better, I agree. But then how do we specify the actual package name (on JVM) ?

[wcaokaze]

Also, it seems two (or more) module declarations can be mixed in one projects. This can crash old source code.

[wcaokaze]

How about module-info.kt like Java? Isn’t it pragmatic?

[gildor]

I think this proposal will never be confirmed
First of all, those changes are backward incompatible, so never be a part of Kotlin 1.x

[gildor]

Explicit import has really good performance benefits in terms of compilation, compiler can much faster resolve members from imports

[gildor]

also many style guilde do not allow to use “star imports” at all because of good reason: it allows to avoid some bugs

[gildor]

and I don’t see why you need this?
I never write imports manually and actually never see them, IDE do this for me and collapse imports

[gildor]

Interesting, that original import example has 22 imports, but “ideal version” 16, not a big difference to be honest

[gildor]

Nothing prevents you from usage of own default package:
App or app,
so:
import com.wcaokaze.app.util.*
becomes
import app.util.*
instead of proposed
import App : util

[wcaokaze]

Those changes are compatible. import without module names will continue to be available.

[wcaokaze]

But other indications are right.
I just want to specify modules which the file depends on. We don’t need this immediately

[gildor]

Why not just usу ModuleName as basic package name instead of com.wcaokaze.modulename, there is a lot of libraries that do that

[gildor]

and it’s completely fine for applications

[gildor]

import android.view

import android.widget

so this import all the members of android,view and widget packages to your code recursively? Looks really scary

[gildor]

Except compiler performance penalty I suppose it would be even worse for IDE, now at least imported members has higher priority in autocomplete

[wcaokaze]

ModuleName as basic package name?
There is import Twitter : timeline in my “ideal imports”. Do you mean I should use import twitter.timeline.fetchHomeTimeline, for example?

[wcaokaze]

🤔

[wcaokaze]

Good point

[gildor]

Yes, import twitter.timeline.fetchHomeTimeline or just import twitter.fetchHomeTimeline if you really don’t care about additional package and just have class Timeline with this function in twitter package

[gildor]

module Baz is better, I agree. But then how do we specify the actual package name (on JVM) ?

import baz, just use short package name without revered domain prefix, no need to invent modules

[benleggiero]

I would like this much better if it were like this:

Current:

package com.wcaokaze.app.activity.twitter.home

   import android.app.Activity
   import android.os.Bundle
   import android.view.*
   import android.widget.EditText
   import android.widget.ImageView
   import android.widget.TextView
   import android.support.v7.widget.RecyclerView
   import android.util.*

   import com.wcaokaze.app.R
   import com.wcaokaze.app.widget.TimelineRecyclerViewAdapter
   import com.wcaokaze.app.util.*
   import com.wcaokaze.app.util.view.*
   import com.wcaokaze.app.util.layout.dsl.*
   import com.wcaokaze.cachemodule.StatusCacheManager
   import com.wcaokaze.cachemodule.UserCacheManager
   import com.wcaokaze.twittermodule.Status
   import com.wcaokaze.twittermodule.User
   import com.wcaokaze.twittermodule.timeline.fetchHomeTimeline

   import java.util.*
   import kotlinx.coroutines.experimental.async
   import kotlinx.coroutines.experimental.launch
   import kotlinx.coroutines.experimental.android.UI

Ideal:

module App
   package activity.twitter.home

   import module Twitter
   import module Cache
   import module App
   import module Android
   import module Kotlinx.Coroutines

   import java.util.*

[wcaokaze]

importing all objects of modules? As Andrey saying, it looks scary, isn't it?

[benleggiero]

I have never had a problem with it in my tests (I have a library, LatteFX, where every file is in the LatteFX package, so you just call import LatteFX.*). Ambiguity is actually very rare, and easily resolved at the call site

[wcaokaze]

Is it easily? LatteFX.Foo is easily but com.wcaokaze.module.Foo is not.
In conclusion, is it best solution to use package name without domain prefix?

[wcaokaze]

Or we can use import as to resolve ambiguity

[benleggiero]

My point is that, with the convention I use with the flattened package hierarchy, I've not run into any issues.

I'm not saying everyone should flatten their packages. I'm saying that I'm doing this as a proof-of-concept that it's not a burden on developers to import the whole module like I suggested above.

[wcaokaze]

I see. For small modules it will work fine, but import module Android looks scary I think

[benleggiero]

I suppose. I'm just inspired by how Swift and Obj-C can just import everything in one line with import Cocoa or #import <Cocoa/Cocoa.h>. That's the entirety of the macOS development platform, and just a couple characters different from the entire iOS platform.

And those don't really affect compilation times. I'm not 100% sure what the technical difference is with JVM imports, but I feel like, since IntelliJ already searches through everything even if it's not imported, JB can make Kotlin do the same and only encode the necessary imports into the bytecode

[wcaokaze]

Okay I believe in you. Now we have another issue;

module App
package activity.twitter.home

Which the actual package (on JVM) will the file belong to?

[benleggiero]

For the bytecode, I think an explicitly-defined package takes precedence over any defined module. I guess if there’s only a module declaration that could implicitly double as a package declaration?

[wcaokaze]

In my proposal, package com.wcaokaze.app.activity.twitter.home will become package activity.twitter.home since the module's "root package" is com.wcaokaze.app.

[wcaokaze]

But in yours, modules have no information about packages, so package declarations always have full name, right?

[gildor]

How would this proposal work with Java 9 modules? Isn't it too confusing to use word module for package alias?

[gildor]

JB can make Kotlin do the same and only encode the necessary imports into the bytecode

Isn't this "compile time penalty"? Compiler should infer target class/member of class on comile time and include to bytecode.
But not like IDE, which works only with a single file, but actually do this for all files of project each time (or you need some support of incremental resolution if you want to somehow reduce penalty)

I just thing it's fight with non-existent problem.
Kotlin plugin is really good helper with dependency, I never import manually and I always know which class/function I just imported