http://d.puremagic.com/issues/show_bug.cgi?id=453

           Summary: When importing modules compiler can not distinguish
                    between directory and file
           Product: D
           Version: 0.169
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: aarti@interia.pl


...

It cause problems when there is same name of file as a name of directory.

E.g. Directory:
doost/program_options/a.d
doost/program_options/b.d
doost/program_options/c.d
doost/program_options.d

Program:
import doost.program_options;

Above cause error, although it is easy to see that I mean file not a directory (AFAIK last part of import is always file).

It's quite a basic problem, so I thing it should be corrected in the first place. It causes unnecessary problems when porting code from C++ and disallows creating program directory structure in the way designer wants.


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=453
> 
>            Summary: When importing modules compiler can not distinguish
>                     between directory and file
>            Product: D
>            Version: 0.169
>           Platform: Other
>         OS/Version: All
>             Status: NEW
>           Severity: normal
>           Priority: P2
>          Component: DMD
>         AssignedTo: bugzilla@digitalmars.com
>         ReportedBy: aarti@interia.pl
> 
> 
> ....
> 
> It cause problems when there is same name of file as a name of directory.
> 
> E.g. Directory:
> doost/program_options/a.d
> doost/program_options/b.d
> doost/program_options/c.d
> doost/program_options.d
> 
> Program:
> import doost.program_options;
> 
> Above cause error, although it is easy to see that I mean file not a directory
> (AFAIK last part of import is always file).
> 
> It's quite a basic problem, so I thing it should be corrected in the first
> place. It causes unnecessary problems when porting code from C++ and disallows
> creating program directory structure in the way designer wants.
> 
> 

This has come up many times before, and unless Walter has had a severe change of heart (and some genius insights) it won't be changing.  Allowing modules and packages to share a name introduces all manner of namespacing conflicts and ambiguities... effectively, imports break down entirely (particularly if any more naming conflicts occur deeper into the namespacing).

-- Chris Nicholson-Sauls

Chris Nicholson-Sauls napisał(a):
> d-bugmail@puremagic.com wrote:
>> http://d.puremagic.com/issues/show_bug.cgi?id=453
>>
>>            Summary: When importing modules compiler can not distinguish
>>                     between directory and file
>>            Product: D
>>            Version: 0.169
>>           Platform: Other
>>         OS/Version: All
>>             Status: NEW
>>           Severity: normal
>>           Priority: P2
>>          Component: DMD
>>         AssignedTo: bugzilla@digitalmars.com
>>         ReportedBy: aarti@interia.pl
>>
>>
>> ....
>>
>> It cause problems when there is same name of file as a name of directory.
>>
>> E.g. Directory:
>> doost/program_options/a.d
>> doost/program_options/b.d
>> doost/program_options/c.d
>> doost/program_options.d
>>
>> Program:
>> import doost.program_options;
>>
>> Above cause error, although it is easy to see that I mean file not a directory
>> (AFAIK last part of import is always file).
>>
>> It's quite a basic problem, so I thing it should be corrected in the first
>> place. It causes unnecessary problems when porting code from C++ and disallows
>> creating program directory structure in the way designer wants.
>>
>>
> 
> This has come up many times before, and unless Walter has had a severe change of heart (and some genius insights) it won't be changing.  Allowing modules and packages to share a name introduces all manner of namespacing conflicts and ambiguities... effectively, imports break down entirely (particularly if any more naming conflicts occur deeper into the namespacing).
> 
> -- Chris Nicholson-Sauls


I am not trying to enforce anything - maybe it's really not good to include such a feature to compiler - I don't try to solve this problem.

But if current status quo must be kept, it should be clearly stated in documentation with short explanation (rationale), as it is quite restrictive.

I am writing from the "still newbie" position (only one year looking at D newsgroup), so I am sure that this issue will continuously come back later, when new people will give a try to D Language.

Regards
Marcin Kuszczak
Aarti_pl

http://d.puremagic.com/issues/show_bug.cgi?id=453


bugzilla@digitalmars.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




------- Comment #3 from bugzilla@digitalmars.com  2006-10-25 17:23 -------
Cannot fix because if name were both a module and a directory name,

    import name;
    import name.foo;

the two uses of name could not be distinguished.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=453





------- Comment #4 from digitalmars-com@baysmith.com  2006-10-25 18:22 -------
(In reply to comment #3)
> Cannot fix because if name were both a module and a directory name,
> 
>     import name;
>     import name.foo;
> 
> the two uses of name could not be distinguished.
> 

Why is that? The documentation states the following:

The Identifier preceding the rightmost are the packages  that the module is in. The packages correspond to directory names in the source file path.

Therefore, I would interpret the first import statement as importing the module name, and the second import statement as importing the module foo in the package name.

Can't packages be distinguished from modules?


-- 

d-bugmail@puremagic.com wrote:
> Can't packages be distinguished from modules?

Consider the following:

	int F;
	class F { }

That doesn't work either. Cannot have two identical names in the same scope mean different things.

Now consider:

	import name;		// name.d
	import name.foo;	// name\foo.d

and in the code:

	name.foo.bar;

is that foo.bar inside name.d, or bar inside name\foo.d? It's not going to work.

Walter Bright wrote:
> d-bugmail@puremagic.com wrote:
>> Can't packages be distinguished from modules?
> 
> Consider the following:
> 
>     int F;
>     class F { }
> 
> That doesn't work either. Cannot have two identical names in the same scope mean different things.
> 
> Now consider:
> 
>     import name;        // name.d
>     import name.foo;    // name\foo.d
> 
> and in the code:
> 
>     name.foo.bar;
> 
> is that foo.bar inside name.d, or bar inside name\foo.d? It's not going to work.

I see your point. From my point of view, this is simply another case of symbols conflicting, similar to symbols with the same name imported from different modules. When that happens, the compiler reports the problem, and I have to resolve it. Couldn't the compiler look for name.foo.bar in both name.d and name\foo.d, and report an ambiguity if one exists? For example:

dmd main.d name.d name\foo.d
main.d(6): Error: name.foo.bar has multiple definitions: foo.bar in name.d(4), and bar in name\foo.d(2)

----- name.d -----
struct F {
  int bar = 1;
}
F foo;

----- name\foo.d -----

int bar = 2;

----- main.d -----

import name;
import name.foo;

void main() {
  printf(name.foo.bar);
}

Consider this:

	int Foo;
	class Foo { const int bar = 3; const int min = 4; }

and the code:

	Foo + 3;	// use the int Foo
	Foo.max + 3;	// use the int Foo
	Foo.bar + 3;	// use the class Foo
	Foo.min + 3;	// error, ambiguous

D can be made to work that way. I don't think it's a good idea, however. It'll be a major source of confusion, and bizarre special cases.