On 11/05/2015 09:42 PM, Ali Ebrahimi wrote:
Hi,

On Thu, Nov 5, 2015 at 11:43 PM, Peter Levart <peter.lev...@gmail.com <mailto: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.

What I'm trying to say is that it should be the same. situation1 should construct the same readability graph as situation2 (which is the right one).


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.

Right. I would say it even simpler: take the implicitly and explicitly required module names "symbolically" and evaluate them in the context of each module.

This way adding a "public" keyword is always safe and the existence of "public" keyword can not harm anybody. Removing it is of course not safe and can not be made safe.

Regards, Peter




--

Best Regards,
Ali Ebrahimi

Reply via email to