DIP16: Transparently substitute module with package

[deadalnix]

Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
> 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

I know. I think you answered too fast.

I wasn't stating that public import are the same as what you propose. I 
was discussing the fact that both probably answer the same need and that 
2 different syntax is something to avoid.

Code wouldn't be broken in unexpected way, because thing will cause 
either a compile error (collision of names, but the problem exists with 
other solutions too) or is illegal in the current shape of the language.