Dart imports system

[JFixby]

Hello,

I just want to put in my two cents on the issue and document this concerns about code imports in Dart.
I don't expect anyone to take it seriously. I totally understand the issue has the lowest priority and I apologise for any inconvenience caused.

Designing imports system makes sense to take in account Java. The language has a very powerful imports management with a very simple and reliable syntax.

Example:

import com.company.libraby.package.Class;

1. That namespace is wider than the intended language. Import refers to concept in a knowledge domain, not to a specific class. Since no files are mentioned in the import the naming works outside Java language.
2. Import syntax has no references to a project name (in contrary to the Dart). Client code doesn't know and doesn't care about the source if the import. The client delegates the responsibility of providing its dependencies to external system like IDE or a runtime environment.
3. Name conflicts are resolved using explicit import. If you have a class that refers to the Map interface and some other geographical Map, you can call classes with their full names like com.java.util.Map and org.geography.Map. No need obscuring your code with import A as B-type statements.

Here I documented some of the most obvious import refactoring problems I encountered (let me know if you have any workarounds.):
#30294
#30295
#30296
#30297
#30298

All of the mentioned problems are nicely solved in Eclipse IDE for Java developers. So there is proven track record of success for the naming convention.

Key points of it's success:

1. All public classes are exported by default. No need the export operator.
2. When you move classes between projects you no need to do refactoring at all. (solves Moving code from one package to another doesn't update dependencies #30298)
3. IDE takes the job of automatic imports resolution (helps to solve Missing import suggestions #30295 Imports refactoring: changing import folder fails to update dependent classes #30294 Optimize imports command doesn't resolve imports automatically #30296 Dependent project can't see ext imports to make suggestions #30297)

Thank you for your attention to this matter.

[JFixby]

@matanlurey

[JFixby]

I may propose an elegant solution for this:

1. Keep original import statements as is for backward compatibility and call them the legacy imports.

2. Add the new format import com.company.libraby.package.Class; as second option. The new import are resolved by IDE and runtime environment and Pub.

3. Add import resolution config files to specify resolution policy. The policy file resolves the new import statements and can be managed by IDE plugin.

Example benefits:

• All org.dartlang.pub.* imports are resolved to Pub packages.
• New import can be easily resolved to the legacy one simply by specifying the file path.
• Resolution config file can contain instructions about optional imports and many other cool features you dream about.

@bwilkerson
@matanlurey
@zoechi