On Wed, 15 Jun 2011 12:35:07 -0400, Andrei Alexandrescu <seewebsiteforem...@erdani.org> wrote:

On 6/15/11 11:00 AM, Adam D. Ruppe wrote:
I understand the appeal, but I also understand the inherent
limitations of HTTP versus a file system. I don't think it's wise
pounding the former into the shape of the other.


AIUI, you can't search for a module on a local filesystem either,
aside from guessing a name. In D, a module name doesn't necessarily
have to match the file name.

If you import foo.bar;, you have two options:

call it foo/bar.d

pass whatever.d that has "module foo.bar;" in it on the command
line explicitly.


Being able to do a list directory entries feature doesn't really
help locate a given named D module anyway.

OK, good point. Still search is going on across all -I paths, which I think we shouldn't extend to URLs.


I thought of a good reason why -Iurl is likely to cause problems:

-Ihttp://xxx.yyy.zzz/package1 -Ihttp://aaa.bbb.ccc/package2

import a;

if xxx.yyy.zzz/package1 and aaa.bbb.ccc/package2 both contain a module called a, then which one is used depends on the conditions of the network. For example, xxx.yyy.zzz could go offline momentarily, and so package2 is used. Or xxx.yyy.zzz/package1 could be moved to a different url.

I know this is a remote possibility, but like you said, internet urls are not the same things as files.

I propose the following:

1. the parameter to -I (called an import path) can have an optional equals sign in it. If the equals sign is present, then the form is:

full.module.path=<path_to_module>

If this is the case, then failure to find full.module.path.x module inside the given path is recorded as an error (i.e. no other paths are searched).

2. we have a pragma(importpath, "<valid_import_path>"); which makes dmd treat the imports from that specific file as if -I<valid_import_path> was first in the path list. If the imported file is indirect (i.e. foo.d imports bar.d which imports baz.d), then the pragma'd path does not count when parsing the indirect file.

3. <path_to_module> can be either a file path or a url.

4. remote paths are treated like I've specified elsewhere, where the -I parameters of dmd (+ the pragmas) would be passed to dget.

I think this should give us maximum flexibility, and fit within the current system quite well -- as well as giving us more specific import control even for local paths.

-Steve

Reply via email to