On Mon, 02 Nov 2009 10:40:50 -0500, Andrei Alexandrescu
<[email protected]> wrote:
Steven Schveighoffer wrote:
On Sun, 01 Nov 2009 01:28:56 -0400, Andrei Alexandrescu
<[email protected]> 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
