Language: split library scope from imports scope

[rakudrama]

There is a problem that a name may be defined by #import or by a definition in the current library. A change to the imported library can break a program by introducing a clashing name.

The advice is to always #import with a prefix. This is onerous - forcing the programmer to use the prefix on all references to imported names just to protect against a hypothetical future change. In practice, prefixes are avoided until a problem occur.

I suggest that imports happen into a scope surrounding the current library. This would reduce a clash in an imported library to an override warning and at the same time ensure the current library's behaviour did not change.

imports scope
. library scope

This is somewhat similar to the scope of formal parameters being outside that of local variables.

Function scopes:
. parameters
. . local scope
. . . nested local scope...

Putting the imports library outside the current library scope would be compatible with first-class libraries (which would work somewhat like functions).

The imports scope could also have a user-friendly resolution of clashes between two imported libraries: there is only an error if the clashing name is referenced.

---

This would open the way to importing such that prefixes are mostly optional. The #import could specify that the prefix is optional, in which case a missing prefix would find non-clashing names in the imports scope. The prefix itself would be in the importing library's scope.

It is also possible that splitting the library scope would be expanded to give a more nuanced interaction between superclass and library scopes, e.g.

import scope
. superclass scope
. . library scope
. . . class parameter scope (generic types)
. . . . class scope
. . . . . method parameters scope
. . . . . . local scope

As always, a shadowing is a warning that may be suppressed by a TDB mechanism.

[gbracha]

Set owner to @gbracha.
Added Accepted label.

[efortuna]

+1. As another "real code" example of why this is aggravating to the developer, consider our dart tests. Each test has its own main method so that it can be run individually, but for the test runner, we have to import each test with a prefix only because the test runner also has a main method.

[gbracha]

We've decided to support this. Spec fix will be forthcoming.

---

Added this to the M1 milestone.
Removed Priority-Medium label.
Added Priority-High, Started labels.

[gbracha]

Fixed in 0.09 draft.

---

Added Done label.

[gbracha]

Implementation bugs associated with this bug:

issue #2945 (VM)
issue #2946 (dart2js)

[gbracha]

One more detail, as of spec version 0.11: conflicts are only reported if they are used (and re-export counts as a use). See section 12.2.

[DartBot]

This comment was originally written by [email protected]

---

Just as a suggestion... Why don't you allow naming of imports to avoid conflicts as in the following:

#import('somelib.dart') to somelib;
#import('someotherlib.dart') to someotherlib;

foo() => print('foo!');
main() => somelib.foo(); // doesn't conflict with the local or someotherlib's definitions

[DartBot]

This comment was originally written by @chrisbu

---

@cengiz - you can do this with prefix:

#import('somelib.dart', prefix:'someLib');
#import('someotherlib.dart', prefix:'someotherlib');

foo() => print('foo!');
main() => somelib.foo(); // doesn't conflict with the local or someotherlib's definitions