[Issue 11330] Directory named as imported module should not stop module search

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=11330



--- Comment #9 from Vladimir Panteleev <thecybershadow at gmail.com> 2013-10-27 00:37:00 EEST ---
(In reply to comment #7)
> 1. The compiler has always relied on a "first found" algorithm when searching
> the import paths. That's like using nested scopes when searching for a symbol.
> This is a valuable feature as it allows for overriding (and I use this,
> especially when debugging). There's a clear hierarchy of this. (The
> anti-hijacking support in D comes into play for cases where there is no clear
> hierarchy.)

I don't see how a list of search paths is like a number of nested scopes. One
is a flat list, the other has clear hierarchy.

This is besides my argument, anyway, so I understand you're replying about the
suggestion for module hijack protection? This quote:

> I understand that the goal is to avoid hijacking when a package.d file is
> added.

If that's not the case, then it's even more unclear to me why this change was
introduced, and why it is considered beneficial.

> 2. The import system is designed to map onto the file system. Using
> file/directory names that match module/package names is how it is supposed to
> work, if there are matching names that have nothing to do with D will cause
> problems.

This does not address my arguments in comment #2.

Also, without context, your quote can be used to defend a hypothetical change
in DMD to reject "modulename.txt" files, if they exist in the search path and
"modulename" is imported somewhere, which is absurd. Which is the main point of
my argument: D compilers should not treat filesystem directories that match
imported D modules as if they are made for use for D. ".d" files are for D
compilers, directories are for everyone.

As far as I know, no other implementation of a package system in any other
language behaves as DMD behaves now.

> I'm going to resolve as wontfix for now. If a workable solution appears, please
> reopen.

I hope this isn't an attempt to sweep a regression under the rug to get 2.064
out quicker:
- I have stumbled upon this problem twice, in two different situations.
- This change affected two other users (issue 11241 and issue 11243).

I would appreciate a prompt formulation of the problem that this change was
supposed to solve, and the constraints that solutions must meet, so we can work
on a solution that satisfies all use cases and have it implemented before
2.064's release. Right now I don't have much to work with.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------