www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - module hijacking

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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?


Andrei
Oct 31 2009
next sibling parent davidl <davidl nospam.org> writes:
在 Sun, 01 Nov 2009 13:28:56 +0800,Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> 写道:

 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

There must be some bug reports related to this issue, at least mine. But I report it in a way that I didn't aware the cause is this. After I realized the issue, and I was too lazy to change the bug reports.
 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?


 Andrei

We definitely need to prevent the module level hijacking. But there isn't any effective way of correcting the current behavior. The hijacking can occur especially when you don't handle the build tool correctly, meaning the include path not set correspondingly, while you use both tango and phobos. -- 使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
Nov 01 2009
prev sibling next sibling parent reply hasenj <hasan.aljudy gmail.com> writes:
Andrei Alexandrescu 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?
 
 
 Andrei

This is also possible in python. Has this ever caused a real problem? or is it just a theoretical problem?
Nov 01 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
hasenj wrote:
 This is also possible in python.
 
 Has this ever caused a real problem? or is it just a theoretical problem?

In Python, this has caused problems for me. It's less likely to cause a problem in D because D makes better use of packages. Python just dumps everything into the root package; D has 'std'. -- Rainer Deyke - rainerd eldwood.com
Nov 01 2009
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
hasenj:
 Has this ever caused a real problem? or is it just a theoretical problem?

Yes, this is a real problem, that in Python has caused a little wasting of time now and then. But it's not a high danger, so we may chose to try to fix it later. And if/when we want to fix/avoid it, we must be careful to not turn the medicine to cure it into something that has side effects worse than the problem itself. Python devs are well aware of this problem (every month a newbie post a problem caused by this), but a lot of time ago they have chosen to not fix it, thinking that the possible solutions are not nice. Bye, bearophile
Nov 01 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
hasenj wrote:
 Andrei Alexandrescu 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?


 Andrei

This is also possible in python. Has this ever caused a real problem? or is it just a theoretical problem?

I just must describe things clearly one way or the other in TDPL. Andrei
Nov 01 2009
prev sibling next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 01 Nov 2009 01:28:56 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail 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
Nov 02 2009
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Steven Schveighoffer wrote:
 On Sun, 01 Nov 2009 01:28:56 -0400, Andrei Alexandrescu 
 <SeeWebsiteForEmail 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. Andrei
Nov 02 2009
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 02 Nov 2009 10:40:50 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 Steven Schveighoffer wrote:
 On Sun, 01 Nov 2009 01:28:56 -0400, Andrei Alexandrescu  
 <SeeWebsiteForEmail 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?

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
Nov 02 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
Steven Schveighoffer, el  2 de noviembre a las 10:59 me escribiste:
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?

Maybe this can be addressed by adding relative imports like in Python 2.5+ import my_foo = .foo; // look for dirname(__FILE__)/foo.d, error if not found import ..foo: bar; // dirname(__FILE__)/../foo.d, error if not found import foo; // regular search path Relative imports are always aliased or subject to importing single symbols because .foo is not a valid symbol name. I think import ...foo; could be allowed by making it a shortcut to import foo = ...foo; See http://www.python.org/dev/peps/pep-0328/ for the complete proposal. The Python community already had to deal with this (maybe for different reasons though), maybe we can learn something from it. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Yo soy peperino el que siempre pone el vino, yo soy aquel que come los huevos con tocino. -- Peperino P贸moro
Nov 02 2009