DIP16: Transparently substitute module with package

[Michel Fortin]

On 2012-04-05 11:46:38 +0000, "Steven Schveighoffer" 
<schveiguy at 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.fortin at michelf.com
http://michelf.com/