DIP16: Transparently substitute module with package

[deadalnix]

Le 05/04/2012 23:43, Andrei Alexandrescu a écrit :
> On 4/5/12 4:26 PM, Steven Schveighoffer wrote:
>> On Thu, 05 Apr 2012 17:00:56 -0400, Jonathan M Davis
>> <jmdavisProg at gmx.com> wrote:
>>
>>> On Thursday, April 05, 2012 15:30:17 Steven Schveighoffer wrote:
>>
>>>> I don't see how. Just move the code into another module and publicly
>>>> import that module from std/algorithm.d. Problem pretty much solved.
>>>
>>> The issue is code organization. If you want to split up std.algorithm
>>> (or
>>> std.datetime or whatever) into multiple modules, you have to create a
>>> new
>>> package with a completely different name with no connection to the
>>> original
>>> save for the fact that the original publicly imports it.
>>
>> My view is that people will not import the smaller modules, they will
>> only ever import std.algorithm.
>
> I think we should be looking for a solution that not only allows
> replacing module -> package transparently, but also allows people to
> import the newly introduced fine-grained modules.
>
> Andrei
>

Why not limit name collision to name which make sense ?

For instance, import std.a.b.c is a module. if it refers also to a 
function, this import doesn't make any sense, so, even if we have a name 
collision, this isn't a big deal (except maybe for reflection ?).

Same goes for std.a.b.c(); which is a function call, and obviously not 
the module. Here what I propose to resolve names :

1/ import does always find the .d corresponding file. No exception.
2/ Module a.b.c is in package a, a.b and a.b.c . Any package declaration 
in a.b.c match package a.b (one level is removed).
3/ When a name is used in the code and have to be resolved, the 
following process occurs :
  - The compiler find all stuff that have this name.
  - The compiler discard all stuffs that have this name and doesn't make 
sense.
  - If all remaining items are overload of the same item, then standard 
best match rule apply.
  - If all remaining items aren't in the same module, or overload or 
different items, an error occurs. This is never a problem in the case of 
big modules splitted in submodules.

Some examples :

a.d

public import a.b;  // import a/b.d

class b {
     static void foo() {}
}

****************

a/b.d

public import a.b.c;  // import a/b/c.d

void foo(int i) {}

****************

a/b/c.d

void foo() {}

****************

main.d

import a;

foo();  // foo from a/b/c.d
foo(2);  // foo from a/b.d
a.foo();  // foo from a/b/c.d
a.b.foo();  // Error, match both a/b.d and a/b/c.d
a.b.foo(2);  // foo from a/b.d
a.b.c.foo();  // foo from a/b/c.d