Le 05/04/2012 14:58, Steven Schveighoffer a écrit :
On Thu, 05 Apr 2012 08:49:24 -0400, deadalnix <deadal...@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.
