module hijacking

[Steven Schveighoffer]

On Mon, 02 Nov 2009 10:40:50 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Steven Schveighoffer wrote:
>> On Sun, 01 Nov 2009 01:28:56 -0400, Andrei Alexandrescu  
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> I ran the following experiment:
>>>
>>> mkdir deleteme
>>> cd deleteme
>>> mkdir std
>>> touch std/algorithm.d
>>> echo 'import std.algorithm; void main(){int a, b;swap(a,b);}' >main.d
>>> dmd main
>>>
>>> The attempt to compile main fails with "undefined identifier swap",  
>>> which means that the module I defined in the current directory  
>>> successfully hijacked the one in the standard library.
>>>
>>> The usual D spirit is that a symbol is searched exhaustively, and  
>>> attempts at hijacking are denounced. In the module cases, it turns out  
>>> that an entire module can successfully hijack another.
>>>
>>> Walter and I are ambivalent about this. There has been no bug report  
>>> so it seems like people didn't have a problem with things working as  
>>> they are. But maybe they never hijacked, or maybe some did hijack.
>>>
>>> Question: should we change this?
>>  No.  This is completely the opposite of hijacking.  I would consider  
>> it hijacking if I had a project with a blah/file.d and the standard  
>> library added a blah/file.d that overrode *my* file.
>>  -Steve
>
> The opposite of hijacking would be if any duplicates found would be an  
> error.

No, this is also a form of hijacking -- namespace hijacking.

example:

I write an application, defining a small internal library foo.  I put a  
module bar in the foo directory, and import foo.bar in my main program.

Now, someone compiles it on his system and happens to have a globally  
installed foo library (completely unrelated to my app-specific foo  
library) with a module bar.  The compiler sees both and throws an error?   
Now I have to deal with the possibility that any library can kill the  
ability to compile my app by naming its directories the same?

-Steve