Hi,
On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.lev...@gmail.com>
wrote:
>
>
> On 11/05/2015 07:39 PM, Ali Ebrahimi wrote:
>
> Hi,
> So with current implementation of Implied readability w.r.t. layers and
> unexpected consequences of its remove or addition, I strongly propose to
> drop it from current design.
>
>
> Unless the rule is very simple. The implied readability should be no
> different than explicit readability.
>
> ...in all possible configurations of layers and classloaders.
>
Exactly. I agree.
Now suppose we have foo, bar@1 in layer1 and baz and bar@2 in layer2.
situation1:
module foo {
requires public bar;
...
}
module baz {
requires foo;
...
}
The readability graph for configuration1/layer1 is:
bar@1 reads java.base
foo reads java.base
foo reads bar@1
The readability graph for configuration2/layer2 is:
bar@2 reads java.base
baz reads foo
baz reads bar@1==================
But situation2:
module foo {
requires bar;
...
}
module baz {
requires foo;
requires bar;
...
}
The readability graph for configuration1/layer1 is:
bar@1 reads java.base
foo reads java.base
foo reads bar@1
The readability graph for configuration2/layer2 is:
bar@2 reads java.base
baz reads foo
baz reads bar@2==================
> If implied readability is taken "symbolically", the same caveats apply to
> one or the other form - they are just different forms of expressing the
> same thing.
>
As you can see this is currently is not case.
But with one simple rule "Always current layer's version of module win over
parent layer's one" we would have same readability graphs for both
situations.
--
Best Regards,
Ali Ebrahimi
