DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 10:33:14 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> 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.

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