Aliases
Paul Sandoz
paul.sandoz at oracle.com
Mon Sep 10 01:16:19 PDT 2012
Hi,
Aliases, unlike views, currently have version numbers that can be independent of the version of the module itself.
In the following example:
module x at 1 {
requires a;
}
module b at 1 {
alias a at 3;
}
module b at 2 {
alias a at 2;
}
module b at 3 {
alias a at 1;
}
where x at 1 is the root, what should the resolved set of modules be for compilation (select the lowest version of a module in the range)?
[x at 1, b at 3] or [x at 1, b at 1]
It all depends on whether the module versions of b or the alias version of a are selected.
In the following example:
module x at 1 {
requires optional a@<3;
}
module y at 1 {
requires a at 3;
}
module b at 1 {
alias a at 3;
}
module b at 2 {
alias a at 2;
}
module b at 3 {
alias a at 1;
}
where x at 1 and y at 1 are the roots, resolution should fail since only one version of b is allowed in the in the resolved set of modules, *even though* y has an optional dependence of a at 3 [*].
In the following example:
module x at 1 {
requires a@<3;
}
module y at 1 {
requires a at 3;
}
module b at 1 {
alias a at 1;
}
module c at 1 {
alias a at 2;
}
module d at 1 {
alias a at 3;
}
where x at 1 and y at 1 are the roots, the resolved set of modules could be either:
[x at 1, b at 1, y at 1, d at 1] or [x at 1, c at 1, y at 1, d at 1]
Which one to select is arbitrary unless the version range of a is taken into account in which case the solution is:
[x at 1, b at 1, y at 1, d at 1]
So... this would seem to indicate versions ranges of aliases should be taken into account even though only one version of an actual module can be present in a resolved set of modules.
But... it would also seem to indicate that version ranges of aliases add additional complexity in terms of understanding the result of resolution.
Thoughts?
Paul.
[*] Arguably the linking stage could be smart enough not to link x at 1 to a at 3, that works statically but not for dynamic interactions.
More information about the jigsaw-dev
mailing list