On Mon, 02 Apr 2012 20:44:09 -0400, Michel Fortin
<[email protected]> wrote:
On 2012-04-02 13:04:31 +0000, "Steven Schveighoffer"
<[email protected]> said:
On Fri, 30 Mar 2012 17:45:36 -0400, Michel Fortin
The problem is that if .std.algorithm.package
contains a sort function and there is also a module called
std.algorithm.sort, the fully-qualified name of that 'sort' module wil
l
become ambiguous. Moreover, whether the fully-qualified name
.std.algorithm.sort is ambiguous or not depends on what modules were
imported, which is not a very desirable behaviour.
So this becomes an error. I don't see this as a major problem. Just
don't name a module sort inside std/algorithm.
This is no different than ambiguous templates, which are allowed until
y ou
want to instantiate one.
If you have ambiguous templates in the same module, it'll always be
ambiguous irrespective of what you import (and you can blame the
module's designer for it). If you have ambiguous templates residing in
different modules the symbol will be unambiguous until you've imported
the second module (same as overloaded functions). At that point you can
disambiguate using the fully-qualified name of the template (or
function).
Whereas if the fully-qualified name of a module becomes ambiguous
because of a symbol in another module, there is no way to disambiguate.
All you can do is avoid importing the two conflicting modules together,
just like when you encounter two headers trying to define the same
symbol in C/C++.
How does this happen? The FQN cannot be ambiguous.
For example, if we change std/algorithm.d into:
std/algorithm/sorting.d which defines sort
std/algorithm/finding.d which defines find
std/algorithm/package.d which imports sorting.d and finding.d
Then how can importing some other module make the FQN ambiguous? The FQN
for sort is std.algorithm.sorting.sort. Now, if you define the symbol
sort inside std/algorithm/package.d, you have an ambiguity, but so what?
If you are responsible for the std.algorithm module, aren't you
responsible for all the files in that pseudo-package? I don't see how it
changes things from today. Basically, my point is the only ambiguity FQN
in the package.d file can create is with other symbols within that same
directory, therefore within the same module.
All we have to do is adopt the practice that phobos' package.d will only
publicly import other modules. It won't define any symbols. Then there
will always be an unambiguous FQN.
Hm... maybe you mean if you can have std/algorithm/package.d do something
like import std.file, which contains another sort function, is that now
packaged under std.algorithm.sort? I don't think that's possible in the
given DIP.
-Steve
