Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do with 2+ modules at UNIT level #46

Closed
lizmat opened this issue May 29, 2013 · 1 comment
Closed

What to do with 2+ modules at UNIT level #46

lizmat opened this issue May 29, 2013 · 1 comment

Comments

@lizmat
Copy link
Contributor

lizmat commented May 29, 2013

The -use- command in Perl (6) indicates which file must be loaded, without there being a guarantee that there is actually anything with that name inside it.

This is fine.

However, now that we have the capability (in spec) of having multiple versions of a module (class / package / grammar / etc). residing in memory at the same time, and imports are lexical, so we will be doing "use Foo" far more often than before, we need to look deeper at what "use Module" actually means.

Assume we have a file AAAAA.pm that contains:

module AAAAA { sub a is export { say "a" } }
module BBBBB { sub b is export { say "b" } }

This file is loaded into memory with:

use A:name;

After that the 2 modules exist at the same UNIT level: one under the synonym of "A", and the other with its longname "BBBBB". And all subs (from both modules) marked "is export" are imported. So currently you can not alias another top level module in a -use- statement.

If sometime later in another lexical scope the code say:

import BBBBB;

would Perl 6 need to be able to import from that module, even though in that scope it had not been loaded with "use"?

Alternately, would:

import AAAAA;

work as well, even though the "use" was aliassing the module to "A"? And if that would be possible, shouldn't we allow the full From/Auth/Version selection process on "import" as well?

I guess the whole problem comes from modules specifying their LFAV (longname, from, auth, version) in the module statement, whereas the selection on which version of a module to load, is done at the file (UNIT) level.

One way to solve this, would be to disallow more than one module (class, etc) at the UNIT level. Please note that this would not affect modules embedded in other modules, as these are not visible from the outside anyway, even though they can add to the export list of the outer module. Then we would be sure that the constraint in "use" would be correctly applied to the right module.

We will find other situations, in which the discrepancy between a file and a module in memory, may cause problems. Enforcing having only one module at UNIT level in a file, would make things simpler.

Would be nice if we could discuss and resolve this at YAPC::NA as well!

@lizmat
Copy link
Contributor Author

lizmat commented Jun 12, 2013

Discussed at YAPC::NA: use is only about UNIT level, any loaded modules because of a use are only side-effects, really.

@lizmat lizmat closed this as completed Jun 12, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant