On 1/12/2017 3:44 AM, Stephan Herrmann wrote:
On 01/10/2017 11:24 PM, Alex Buckley wrote:
On 1/10/2017 12:20 PM, Stephan Herrmann wrote:
Can a module export a package even if no compilation units of that
package
are associated with the current module? The export might only affect
types
exported from some other required module. Is that allowed?
There is no re-exporting of another module's packages. Per
lang-vm.html, "It is a compile-time error if the package specified by
exports is not observable in the current module."
Then: "If the package specified by exports is observable in the
current module, then at least one compilation unit containing a
declaration of the package must be observable in the current module,
or a compile-time error occurs."
"observable in the current module" needs to be reworded, but I hope
you can see the intent.
Yes and no. I'm still not sure how to implement this but it helps
to raise new questions: what's the layering of concepts "observable"
and "associated to a module"?
From 7.3 I understand:
- observability is determined by the host system (so JLS doesn't have
the rules)
- if a compilation unit is observable it can be associated to a module
Now you mention a paragraph where "observable" can only be answered
relative to a module, so we first need to know the association to modules
before we can answer observability. This sounds cyclic to me.
Or is "observable" a different concept than "observable in the current
module"?
As you say, observability is the lowest level predicate, then
associated-with is the next level up, then visible-to, then
accessible-to. The lang-vm.html paragraph is not meant to introduce any
new concepts -- it was written before the JLS text, so it uses the
traditional notion of observability and has not yet been reworded to use
the associated-with relation (we need to have cu's+packages associated
with a module for the rule to enforce "in the _current_ module").
Alex
