DIP16: Transparently substitute module with package

[Steven Schveighoffer]

On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix <deadalnix at gmail.com> wrote:

> Le 05/04/2012 13:46, Steven Schveighoffer a écrit :
>> I don't like this proposal, simply because this means one
>> function/symbol per submodule. It should be more flexible than that. But
>> I like the line of thinking.
>>
>> 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
>> than one symbol.
>>
>> I purposely left out the package.d idea because it's orthogonal to this.
>>
>> -Steve
>
> The behavior you described has been proposed for public import, and have  
> been discussed. This is interesting.
>
> You propose an alternative syntax with is fine and have the advantage to  
> not disturb already existing public imports, but have the drawback to  
> create a new syntax, again.
>
> If such a syntax is adopted, what would be the point of public imports ?  
> If it is still useful, then your syntax is a better choice, otherwise,  
> we'd better modify public import.

No, public imports simply mean that you can view the publicly imported  
module.  It does *not* add aliases to the importing module.

for example:

foo.d:

module foo;

int x;

bar.d:
module bar;
public import foo;

int y;

main.d:
import bar; // publicly imports foo.

void main()
{
    foo.x = 5; // ok, publicly imported via bar (non public, this would be  
an error)
    bar.y = 5; // ok
    bar.x = 5; // error, public import doesn't create new fully qualified  
name for foo.x
}

With the system I propose, using the specific technique would make it so  
bar.x would also be valid, and would refer to foo.x

I think we need new syntax, or a new language feature, because you don't  
want to alter the operation of existing code.  Simply changing public  
imports would cause lots of existing code to be reinterpreted, possibly in  
a way not intended, or that would be ambiguous.

-Steve