On 2012-04-05 11:46:38 +0000, "Steven Schveighoffer"
<schvei...@yahoo.com> 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. But for moving a module like
std.algorithm to a package, it's cumbersome.
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.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
