On 5/1/2017 12:23 PM, Stephan Herrmann wrote:
Meanwhile I've come to the interpretation that the main weakness of JLS
concerns
handling of same-named packages in different modules.
Trouble seems to start at a difference between 6.5.5.2 and 6.5.3.1/2:
To identify a type, that type must be accessible from the current module,
but for identifying a package, the package only needs to be visible.
Ergo: identifying a package does not consider exports.
Furthermore, 6.5.3.2 implies that each qualified name uniquely defines a
package,
when it speaks of "the member named Id within the package named by Q".
Note the two occurrences of "the".
Understood. I need to clarify 6.5.* to accept that multiple packages may
be visible by the same name. But when we get to accessibility, only one
of the visible packages should matter.
This finally undermines the definition of accessibility (6.6.1), when it
speaks
of the "module to which the package is exported". I read this as follows:
When M1 exports p1 to M2, this makes all public members of p1 accessible
in M2,
even those that belong to totally unrelated modules, which may not
export p1.
I recall Alex answering "this is still being clarified / discussed" to
several questions in this area.
As a result I can only conclude: JLS still doesn't tell us which module
system to implement.
If this were just a minor omission, why then would it still be subject to
discussion, this late in the game? I see one possible explanation:
changing the
spec may involve much more trouble than meets the eye. Changes
concerning packages
are very much focusing on the hierarchical structure of packages and sub
packages,
despite the fact that 7.1. has always been describing this structure as
having
"no significance in itself".
7.4.3 already jumps through hoops, trying to balance the hierarchy-based
notion of
"technically observable" with the concept of "really observable" which
disregards
the hierarchy.
In my view, a forest rooted at toplevel packages is not suitable for
specifying
the rules of accessibility, where each module may have a different
interpretation
of a given package name, in a way that is completely unrelated to
hierarchy.
Since "exports" refers to a package, this notion must be better aligned
with modules.
It's hard to respond to the same point in multiple sub-threads. Please
see my other mail where I accept that package visibility is unrelated to
'exports'.
Alex
