I would just like to confirm with others that this is the case, and also perhaps raise general awareness about the issue.

The issue is that modules without a package will conflict with a similarly named module in _any_ package.

So for example if there's a module called "foo" and you import it in your project, then your project absolutely CANNOT have another module named "foo" or "blarf.foo" or /anything/ that ends in ".foo" anywhere in the import chain.

For this reason it must be concluded that packageless modules are pure evil, and should never ever be used.  Always always give your modules a package even if it's just repeating the module name like "foo.foo".

Am I right about this?
(and anyone know if module "foo.bar" will clash with "baz.foo"?)

--bb

Bill Baxter:
> For this reason it must be concluded that packageless modules are pure evil, and should never ever be used.  Always always give your modules a package even if it's just repeating the module name like "foo.foo".

If what you say is right, then the solution is to fix the module system of the compiler. It has other "bugs" I have discussed days ago.

Bye,
bearophile

Bill Baxter wrote:
> I would just like to confirm with others that this is the case, and also perhaps raise general awareness about the issue.
> 
> The issue is that modules without a package will conflict with a similarly named module in _any_ package.
> 
> So for example if there's a module called "foo" and you import it in your project, then your project absolutely CANNOT have another module named "foo" or "blarf.foo" or /anything/ that ends in ".foo" anywhere in the import chain.
> 
> For this reason it must be concluded that packageless modules are pure evil, and should never ever be used.  Always always give your modules a package even if it's just repeating the module name like "foo.foo".
> 
> Am I right about this?

What kind of conflict do you mean?  Compiler errors or linker errors? The only linking problem I've seen is that if you have two modules with the same name, the compiler will overwrite one with the other, so only one of them gets linked in.  I guess the -op switch to bud or the compiler will fix this.  dsss avoids this issue by default, as long as you don't have two modules of the same name and both are packageless.

I've come across this issue maybe once, and then I just renamed one of the files to fix it.

> (and anyone know if module "foo.bar" will clash with "baz.foo"?)

Tango has packages and modules with the same name, so it should work.

torhu wrote:
> Bill Baxter wrote:
>> I would just like to confirm with others that this is the case, and also perhaps raise general awareness about the issue.
>>
>> The issue is that modules without a package will conflict with a similarly named module in _any_ package.
>>
>> So for example if there's a module called "foo" and you import it in your project, then your project absolutely CANNOT have another module named "foo" or "blarf.foo" or /anything/ that ends in ".foo" anywhere in the import chain.
>>
>> For this reason it must be concluded that packageless modules are pure evil, and should never ever be used.  Always always give your modules a package even if it's just repeating the module name like "foo.foo".
>>
>> Am I right about this?
> 
> What kind of conflict do you mean?  Compiler errors or linker errors? The only linking problem I've seen is that if you have two modules with the same name, the compiler will overwrite one with the other, so only one of them gets linked in.  I guess the -op switch to bud or the compiler will fix this.  dsss avoids this issue by default, as long as you don't have two modules of the same name and both are packageless.
> 
> I've come across this issue maybe once, and then I just renamed one of the files to fix it.

The problem that prompted this message was that I had a module called just "blas" in one place and was trying to make another module called "dflat.blas".  But that breaks plain "import blas".  It picks up the "dflat.blas" rather than the packageless blas, even though I didn't specify that I wanted "dflat.blas".

>> (and anyone know if module "foo.bar" will clash with "baz.foo"?)
> 
> Tango has packages and modules with the same name, so it should work.

But the top-level package may be special.  I don't think there's a module called "tango" in Tango, is there?

--bb

Bill Baxter wrote:
> The problem that prompted this message was that I had a module called just "blas" in one place and was trying to make another module called "dflat.blas".  But that breaks plain "import blas".  It picks up the "dflat.blas" rather than the packageless blas, even though I didn't specify that I wanted "dflat.blas".

It works when I try a simple test. I have a.d, b/a.d, and then import just 'a' into test.d.

a.d:
---
module a;

char[] s = "a";
---

b/a.d:
---
module b.a;

char[] s = "b.a";
---

test.d:
---
import std.stdio;
import a;

void main()
{
	writefln(s);
}
---

running:
---
c:\prog\test\D\baxter>bud -exec test
a
---

So a more complex test is needed to show the problem.  Maybe importing from different include paths, etc?

This is because you are adding all directories to the import path perhaps?  For example if you do -I. -Iflat then you might have this problem.

-[Unknown]


Bill Baxter wrote:
> torhu wrote:
>> Bill Baxter wrote:
>>> I would just like to confirm with others that this is the case, and also perhaps raise general awareness about the issue.
>>>
>>> The issue is that modules without a package will conflict with a similarly named module in _any_ package.
>>>
>>> So for example if there's a module called "foo" and you import it in your project, then your project absolutely CANNOT have another module named "foo" or "blarf.foo" or /anything/ that ends in ".foo" anywhere in the import chain.
>>>
>>> For this reason it must be concluded that packageless modules are pure evil, and should never ever be used.  Always always give your modules a package even if it's just repeating the module name like "foo.foo".
>>>
>>> Am I right about this?
>>
>> What kind of conflict do you mean?  Compiler errors or linker errors? The only linking problem I've seen is that if you have two modules with the same name, the compiler will overwrite one with the other, so only one of them gets linked in.  I guess the -op switch to bud or the compiler will fix this.  dsss avoids this issue by default, as long as you don't have two modules of the same name and both are packageless.
>>
>> I've come across this issue maybe once, and then I just renamed one of the files to fix it.
> 
> The problem that prompted this message was that I had a module called just "blas" in one place and was trying to make another module called "dflat.blas".  But that breaks plain "import blas".  It picks up the "dflat.blas" rather than the packageless blas, even though I didn't specify that I wanted "dflat.blas".
> 
>>> (and anyone know if module "foo.bar" will clash with "baz.foo"?)
>>
>> Tango has packages and modules with the same name, so it should work.
> 
> But the top-level package may be special.  I don't think there's a module called "tango" in Tango, is there?
> 
> --bb

torhu wrote:
> Bill Baxter wrote:
>> The problem that prompted this message was that I had a module called just "blas" in one place and was trying to make another module called "dflat.blas".  But that breaks plain "import blas".  It picks up the "dflat.blas" rather than the packageless blas, even though I didn't specify that I wanted "dflat.blas".
> 
> It works when I try a simple test. I have a.d, b/a.d, and then import just 'a' into test.d.
> 
> a.d:
> ---
> module a;
> 
> char[] s = "a";
> ---
> 
> b/a.d:
> ---
> module b.a;
> 
> char[] s = "b.a";
> ---
> 
> test.d:
> ---
> import std.stdio;
> import a;
> 
> void main()
> {
>     writefln(s);
> }
> ---
> 
> running:
> ---
> c:\prog\test\D\baxter>bud -exec test
> a
> ---
> 
> So a more complex test is needed to show the problem.  Maybe importing from different include paths, etc?

Ok, thanks for helping me to work through this, torhu.

There may not be any pure evil going on here.  In trying to make a simple repro I've found that if I get rid of the top level a.d (or move it into a different subdir without using a -I to find it), I get the highly misleading error message:

    "b\c.d(4): module b.a is in multiple packages b.a"

So this could be the root of the problem.  I think that was the error I was seeing previously that made me thing it was mixing up the two modules.  I'll dig in a little more and report what I find.

--bb

Bill Baxter wrote:
> torhu wrote:
>> Bill Baxter wrote:
>>> The problem that prompted this message was that I had a module called just "blas" in one place and was trying to make another module called "dflat.blas".  But that breaks plain "import blas".  It picks up the "dflat.blas" rather than the packageless blas, even though I didn't specify that I wanted "dflat.blas".
>>
>> It works when I try a simple test. I have a.d, b/a.d, and then import just 'a' into test.d.
>>
>> a.d:
>> ---
>> module a;
>>
>> char[] s = "a";
>> ---
>>
>> b/a.d:
>> ---
>> module b.a;
>>
>> char[] s = "b.a";
>> ---
>>
>> test.d:
>> ---
>> import std.stdio;
>> import a;
>>
>> void main()
>> {
>>     writefln(s);
>> }
>> ---
>>
>> running:
>> ---
>> c:\prog\test\D\baxter>bud -exec test
>> a
>> ---
>>
>> So a more complex test is needed to show the problem.  Maybe importing from different include paths, etc?
> 
> Ok, thanks for helping me to work through this, torhu.
> 
> There may not be any pure evil going on here.  In trying to make a simple repro I've found that if I get rid of the top level a.d (or move it into a different subdir without using a -I to find it), I get the highly misleading error message:
> 
>     "b\c.d(4): module b.a is in multiple packages b.a"
> 
> So this could be the root of the problem.  I think that was the error I was seeing previously that made me thing it was mixing up the two modules.  I'll dig in a little more and report what I find.
> 
> --bb

Here's a version that causes the problem.  It actually seems to be an issue with build tools rather than DMD itself.

If you put 'test' inside 'b' and then try to build from there with the -I.. flag, the build tools get confused over the two different a.d files.

It seems both bud and dsss get confused about this situation and end up only using one of the a's.  What's interesting is the failure modes are quite different.

Attached is a zip with the setup.

 > cd packageless\b
 > bud -full testit

Gives error:
--> testit.d(4): module b.a is in multiple packages b.a

 > cd packageless\b
 > dsss build testit
 > testit

Builds fine, but outputs "b.a" instead of "a".  This is what I was seeing -- the wrong module gets imported (b.a instead of a).

The problem goes away if you build from the 'packageless' dir one level up instead:

 > cd packageless
 > bud -full b\testit
 > testit

Prints "a" as expected.


So the final moral of the story is either:

    1) don't put test programs in the same directory as package.
   -or at least-
    2) don't build test programs from inside the package directory.

--bb

On Mon, 18 Feb 2008 12:40:02 +0900, Bill Baxter wrote:

> Here's a version that causes the problem.  It actually seems to be an issue with build tools rather than DMD itself.

I'm using BUD v3.05 and I can't get it to go wrong. It works as expected in all four conditions.

PWD = packageless
bud testitok
bud b\testit

PWD = packageless\b
bud ..\testitok
bud testit

So I'm not sure what to do to help.


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/02/2008 3:10:26 PM

On Mon, 18 Feb 2008 15:13:44 +1100, Derek Parnell wrote:

> On Mon, 18 Feb 2008 12:40:02 +0900, Bill Baxter wrote:
> 
>> Here's a version that causes the problem.  It actually seems to be an issue with build tools rather than DMD itself.
> 
> I'm using BUD v3.05 and I can't get it to go wrong. It works as expected in all four conditions.
> 
> PWD = packageless
> bud testitok
> bud b\testit
> 
> PWD = packageless\b
> bud ..\testitok
> bud testit
> 
> So I'm not sure what to do to help.

<DUH manifestation="slaps forehead"> Oh I know what I can do ... release the version of Bud I'm using to the community.</DUH>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
18/02/2008 3:22:50 PM