[jsr294-modularity-eg] Expressing module dependencies

[Alex Buckley]

Richard S. Hall wrote:
>> The tentative 294 spec published in early February had a 'permits' 
>> keyword too. If modules A and B are nodes in a directed graph, then 
>> 'requires' is an edge from A to B, while 'permits' is an edge from B 
>> to A. There is no mystery about the need for "reverse" dependencies as 
>> expressed by 'permits' - it's an encoding of the "provider determines 
>> compatibility" idea we discussed at the EclipseCon BOF.
> 
> I was under the impression that "permits" was some form of poor man's 
> security, not a way of specifying provider compatibility ranges. In 
> other words, I though it was "I permit these other modules to see me."
> 
> Perhaps you could explain it further, but I don't see how listing 
> specific "permitted" modules relates to "provider determines 
> compatibility".

If I am the module A at V, who are the other modules that can see me?

- A simple case: any module whose name is B. All versions of B are 
friends of all versions of A.

- A more advanced case is: any module with exactly my version V. If 
versions are sets of strings representing provided features, then 
friends identify themselves by supporting the same feature set (perhaps 
in addition to other 'permits' constraints).

- Another advanced case is: any module which has a 'requires' dependency 
on A at W where W is in the range [V-1,V]. Thus A at V declares itself 
compatible with its previous major version. Concretely, you might write:

module A @ 3.0 {
   permits <requires A @ 2.0>;
}

Different module systems may support different cases.

In a 'requires' clause, it's obvious that the version of the required 
element can be a query. 'permits' is just 'requires' in reverse, so why 
limit its operand to a module/package name? Then, it's not much of a 
stretch to think about constraining not only the identity of the 
requiring module but its other metadata too.

Alex