module hijacking

[Leandro Lucarella]

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