www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 453] New: When importing modules compiler can not distinguish between directory and file

reply d-bugmail puremagic.com writes:
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.


--
Oct 24 2006
next sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Oct 24 2006
parent Aarti_pl <aarti interia.pl> writes:
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
Oct 25 2006
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=453


bugzilla digitalmars.com changed:

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





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.


--
Oct 25 2006
prev sibling parent reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=453








 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?


--
Oct 25 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Oct 25 2006
parent reply Bradley Smith <user domain.invalid> writes:
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);
}
Oct 25 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Oct 25 2006