Alternative syntax

[lrhn]

Maybe it doesn't have to be all dots. How about:

import dart:async;           // "dart:async"
import package:foo/src/bar;  // "package:foo/src/bar.dart";
import foo/src/bar;          // "package:foo/src/bar.bart", package: is optional/default
import foo;                  // "package:foo/foo.dart", package-name only => default file
import ./foo;                // "./foo.dart"  , starting with "." or ".." means relative.

I think slashes makes it more understandable than using "foo.src.bar" when "src" is really a directory and the library is just called "foo.bar".

[seaneagan]

Making it look more like a url will make people think it acts more like a url. In particular, it may be confusing that the following are not equivalent:

import foo/src/bar
import ./foo/src/bar

Also, the more identifier-based syntax makes further syntactic extensions more natural, such as #4.

[sigmundch]

Interesting idea.

I think slashes makes it more understandable than using "foo.src.bar" when "src" is really a directory and the library is just called "foo.bar".

I think many people out there still use the name foo.src.bar for something under src though.

One reason I was pushing for . and not / is that there is a possibility of creating a syntax that is a valid Dart identifier. That would make it possible to refer to libraries in code using that same identifier. It would (hopefully) also help us find a way to get rid of the discrepancy between library names and how libraries are found.

@seaneagan - good point about the ambiguity, I'd also expect foo and ./foo to be equivalent.

Putting aside my preferences for . (maybe there is an alternative to fix my concerns somewhere else). I wonder what we could do to address Sean's concern, and other concerns raised about the lack of relative paths with the default syntax.

Here are some possible ideas:

1. Use your proposed syntax, but require a leading / to denote "absolute" paths (referring to other packages). For example:

  import dart:async;            // "dart:async"
  import package:foo/src/bar;   // package:foo/src/bar.dart
  import package:foo/foo;       // package:foo/foo.dart
  import /foo/foo;              // package:foo/foo.dart
  import /foo;                  // package:foo/foo.dart
  import /foo/src/bar;          // package:foo/src/bar.dart
  import src/bar;               // relative path
  import ./src/bar;             // relative path, equivalent to src/bar

1. Similar, but use the : to denote an absolute path (: is sugar for package:):

  import dart:async;            // "dart:async"
  import package:foo/src/bar;   // package:foo/src/bar.dart
  import package:foo/foo;       // package:foo/foo.dart
  import :foo/foo;              // package:foo/foo.dart
  import :foo;                  // package:foo/foo.dart
  import :foo/src/bar;          // package:foo/src/bar.dart
  import src/bar;               // relative from here

1. Merge this with the name:path syntax from the proposal. We would use : as a delimiter from the package name to the library path, but use slashes for the path, like this:

  import dart:async;    // "dart:async"
  import foo:src/bar;   // package:foo/src/bar.dart
  import foo:foo;       // package:foo/foo.dart
  import foo:;          // package:foo/foo.dart
  import src/bar;       // relative from here

import foo:; looks a bit odd though.

Interestingly, with this syntax we could use the absolute path / as a self-package reference. for example, on pacakge:p1/dir1/file1.dart:

  import /src/bar;      // would resolve to package:p1/src/bar.dart
  import :src/bar;      // yet another possible alternative syntax

Thoughts?

[sigmundch]

Also, another reason to pick the . syntax is that it would mean that part of directives today would comply with our syntax without making a breaking change (especially if we go with the other DEP about parts). But maybe we could have 3 syntaxes allowed in parts (names, URI, new-fancy-syntax-we-decide-here) and remove support for names when we reach Dart 2.0.

[lrhn]

About using /src/bar to refer to "this package", it would also have to make sense when used from a non-package-URI'ed library. That's a general problem with relative URIs, they depend on the current URI, whetever that is. The :src/bar has the same problem.
Relative URIs work when they are really relative to the current file, but when they change the entire path to something else, it shouldn't make too many assumptions about what the current path is.

[sigmundch]

agree - that relates to sean question in #6, without a canonical way to discover "the current package", this might make no sense in the context of non-package uri'd libraries.