Aliases

[Paul Sandoz]

On Sep 10, 2012, at 8:26 PM, Alex Buckley <alex.buckley at Oracle.COM> wrote:

> I personally think aliases should have versions.

I think so too. If aliases do not have versions are almost like views (one could use views instead).


> The "implementation"
> version of a physical module declaration could be in different universe
> than the "exported interface" version of an alias provided therein.
> 

I am not so sure those universes are distinct given that a view (and therefore an alias) can inherit stuff from the default view.


> But I have some dumber questions first:
> 
> On 9/10/2012 1:16 AM, Paul Sandoz wrote:
>> 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 [*].
> 
> If there was no such thing as an alias, and instead physical modules a at 1/2/3 were available, would resolution still fail?

Yes.


> I know you have been experimenting with resolution of optional dependencies, but I am surprised that "requires optional a@<3" stops resolution - alias or not.
> 

Because the version of b matching y's dependence is not the same as that which matches x's dependence. In the current resolver implementation the solution will fail or pass depending order of requires declarations, i think the former behaviour was the intention of that implementation, and the latter result unintentionally links modules.

But, as i said in the footnote if linking were a bit smarter it might be possible to consider allowing b at 3 in the set of resolved modules as long as x at 1 is not linked to b at 3. I actually implemented such smarter linking with regards to permits, which has similar issues (IIRC i sent some email a while ago on the list in regards to that).


>> 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]
> 
> It is very surprising to see both x at 1 and y at 1 in a resolved set, since they have mutually incompatible dependencies. Could I declare a module m at 1 that requires x at 1 and y at 1, and then resolve with m at 1 as the root?

Yes, at the moment in terms of the current resolver in Jigsaw and one i am experimenting with (more on that in another email soon).


> Surely not.

I reckon it should be possible to detect such a conflict as a post validation step once the set of physical modules have been resolved i.e. it could be viewed as correct from resolving physical modules and then linking verifies.

What about this one:

module r at 1 { requires x; requires y; }
module x at 1 { requires a@<3; }
module y at 1 { requires d at 1; }
module b at 1 { alias a at 1; }
module c at 1 { alias a at 2; }
module d at 1 { alias a at 3; }

?


> I have a feeling the use of multiple roots indicates compile-time, and each "resolved set" is really a set of two sets (one per root).
> 

Actually i was just being lazy avoiding an extra module with the multiple roots :-)


> BTW I like your rule for monotonic alias versioning.

Bingo! i could not think of what to call it.


> (Slightly better formalized as: "Given modules X at i and X at j, where i<=j, any alias provided by X at i must have a version less than or equal to an alias of the same name, if any, provided by X at j.")
> 

Yes, much better.

Here is another potential rule: Given an alias A at k declared in view V at i of module X at i then any alias A at l, where l != k, must be declared in a view V at j of module X at j, where i != j.

i.e. one cannot install two modules into a library that have different names but declare an alias of the same name.

Paul.