Default prefix for library imports

[peter-ahe-google]

I believe the original intent was to provide a default prefix for libraries imported without an explicit prefix.

The default prefix should be what is specified by the #library tag in the imported library.

I believe the current default is wrong and leads to unmaintainable software.

[munificent]

I disagree. I prefer importing without a prefix by default. I find using fully-qualified identifiers everywhere leads to painfully verbose code with no value added. In any reasonable IDE, I can hover over a name to see which library defines it, and I really don't want to have to do:

  new html.Element('...');
  dom.window.console.log('...');

or worse:

  unittest.group('some group', () {
    unittest.test(() {
      unittest.expect(actual).equals(expected);
    });
  });

I strongly believe unqualified names should be the default and qualification should mainly be used to resolve ambiguity.

[peter-ahe-google]

Unfortunately, not using prefixes causes major issues with compatibility: you cannot add a new top-level to a library without potentially breaking all your users.

This is why it makes sense to err on the side of caution.

[gbracha]

I think a combination of required prefix and typedefs would address this. It would still be less convenient then current practice, but much more robust. The tension between those is hard to resolve.

---

Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

[DartBot]

This comment was originally written by @seaneagan

---

If there is a default prefix, I think it should be determined from the URL, not from a #library tag in the imported library, that way conflicts can be determined without downloading all imported libraries. I think the #library tag could be removed in general, since the library is already named from the canonical URL from which it is accessed. For example, the rule could be that the maximal identifier string which immediately precedes any ".dart" suffix is the default prefix:

#import("dart:math"); // math
#import("http://github.com/seaneagan/dart/foo.dart"); // foo
#import("http://github.com/seaneagan/dart/bar"); // bar

[DartBot]

This comment was originally written by [email protected]

---

I recommend a default prefix that can be removed at the importer's request, e.g.

#import("animals"); // animals.*
#import("animals", as: "pets"); // pets.*
#import("animals", as: ""); // no prefix

Since one of Dart's goals is to scale to complex and larger projects than can JavaScript, maintainability and clarity should win by default. While prefixes may make the code more verbose, they make it more readable for future maintainers.

[ Full disclosure: I'm a Python fan partially because Ruby's non-prefixed imports turn me off so much when I'm trying to grok others' code. ]

[anders-sandholm]

Added this to the M1 milestone.

[gbracha]

We've done several things to deal with these issues:

1. Imported names are subsumed by local names.
2. Conflict between imports are only flagged when used, and then can be resolved via hide, show or prefixing.

This greatly reduces the urgency of the issue.

We also re-considered implicit prefixing by default, but decided against it. It is understood that a mandatory prefix would protect the foolhardy from themselves, but that seems excessive. Instead, we make it easy for careful programmers to protect their modules, while allowing the care-free to live as they please.

I think the best practice would be to import using show to explicitly enumerate all imported names, and I expect tools to evolve so that will be painless. This means prefixing is only really needed to disambiguate access to entities with the same simple name.

---

Added NotPlanned label.

[DartBot]

This comment was originally written by [email protected]

---

"I think the best practice would be to import using show to explicitly enumerate all imported names, and I expect tools to evolve so that will be painless. This means prefixing is only really needed to disambiguate access to entities with the same simple name. "

True, but it makes it very hard for the client of every library. Ie, every client would need to be well versed with the contents of the library to properly use show and hide.

Instead, I suggest that we have 2 types of import statements:
1)
#import('foo.dart'); <- import without prefix

import('foo.dart')

The good thing about this is that people will get to use whatever they want. And by using prefix, we can avoid the use of static methods in classes just to avoid clashing of functions. In addition, it could also enable auto-completion of constructors, functions, etc (which is cool).