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 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 reply 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
parent reply "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?


  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
Nov 02 2009
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