Implied readability + layers

[Alan Bateman]

On 05/11/2015 09:30, Ali Ebrahimi wrote:
> Hi alan,
> So far quite disappointing!
>
> But I think Alex's last response on this topic says opposite of this:
>
> "We'll have to think about the implication of com.baz in layer1 
> sometimes offering a 'requires public' on com.bar in layer1, and 
> sometimes offering a 'requires public' on com.bar in layer2, depending 
> on who is reading com.baz in layer1."
>
> In this case adding 'requires public' on com.bar in layer2 does not 
> mean we should pick com.bar at 2 for com,foo?

In this example then com.baz in layer1 doesn't know anything about 
com.bar at 2 or other modules that comes into existence in future "child" 
layers, at least not statically.

com.baz does read com.bar at 1 and as it declares "requires public com.bar" 
then I assume com.baz's exported API must have com.bar at 1 types in its 
method signatories. This will usually be good for other modules in 
layer1 or modules in descendants of layer1 that use the com.baz API.

Creating a new layer2 does not change modules in other layers. This 
means that creating layer2 will not change com.baz (in layer1) to read 
com.bar at 2 (in layer2). It is of course possible for com.baz to opt-in 
and reflectively to read com.bar at 2 but great care is required (static 
references in code in com.baz will presumably resolve to types in 
com.bar at 1).

>
> This scenario would have many usages in future when world would filled 
> with modules and developers would have to use newer versions of 
> modules to fix bugs.
> What if com.foo compiled against com.bar at 2? adding redundant 
> requirescom.bar in com.foo does not help and my app will fail.
Assuming com.bar at 1 and com.bar at 2 export the same packages then it should 
fail when you attempt to create the Configuration for layer2 as com.foo 
cannot read both.

In this example then you might consider a new instance of module com.baz 
in layer2. That way, layer2 would have com.foo, com.baz and com.bar at 2.

-Alan.