On Thu, 05 Apr 2012 10:33:14 -0400, Michel Fortin
<[email protected]> wrote:
On 2012-04-05 11:46:38 +0000, "Steven Schveighoffer"
<[email protected]> said:
I don't like this proposal, simply because this means one
function/symbo l
per submodule. It should be more flexible than that. But I like the
li ne
of thinking.
I have the same reserve about it's lack of flexibility too. It would be
a nice thing to have for all those libraries having one module per class
as it'd reduce the length of the fully qualified name you have to use
when you need to disambiguate.
I see the point you are going for. I don't really like the
one-class-per-module style as much as how phobos has one module per
category. But that's not an excuse not to examine this possibility.
I think it's a different issue than what DIP16/DIP15 is trying to solve.
But for moving a module like std.algorithm to a package, it's cumbersome.
Not really. Just move the files to another directory (i.e.
std/internal/algorithm) and publicly import them.
Let's re-examine the issue. We need to allow splitting of a module X.d
into pieces for maintenance (or possibly accessibility -- disallowing
friends). But we don't want to break code which currently uses FQN to
access X's symbols.
I think the following might work:
algorithm.d:
import this = std.algorithm_impl.sort;
Which then imports std.algorithm_impl.sort, and effectively aliases all
its symbols into algorithm.d. If std.algorithm_impl.sort defines a
function called sort, then it's also aliased to std.algorithm.sort. In
essence, sort has *two* FQN, but there are no FQN that refer to more
tha n
one symbol.
This is what a public import should do.
I wasn't aware of this. Mostly because the spec omits that feature. I
have to retract almost everything I've argued, because we already have the
means to fix what I think DIP16 is trying to solve without any compiler
changes.
-Steve
