package hierarchy?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

package hierarchy?

Stephan Herrmann
This continues a discussion we had in January, but still isn't
fully resolved in JLS 2017-06-26:

Does the parent-sub relation of packages bear any meaning
from the JLS p.o.v.?

On 2017-01-10 Alex conceded:
   "... you can consider all packages as unrelated to each other."

Still JLS 6.5.3.2 has this (my emphasis):

"If a package name is of the form Q.Id, then Q must also be a package name.
  The package name Q.Id names a package that is the member named Id
  *within the package named by Q*.
  If Q does not name an observable package (§7.4.3), or Id is not the simple name
  of an observable subpackage of that package, then a compile-time error occurs.

  If Q.Id does not name a package that is uniquely visible to the current
  module (§7.4.3), then a compile-time error occurs."

Now, what's the meaning of "the package named by Q"?

Technically, we need to consider Q as a package name, whose meaning
is determined by 6.5.3.1 or 6.5.3.2.
This inevitably implies that Q must be uniquely visible.

In the end, this requires, e.g., that package "java" be uniquely visible in
every Java 9 program. Or: every Java 9 program (even JDK itself) is illegal.



I *imagine*, the spec authors intended two different definitions of
PackageName: an internal definition that is applied whenever JLS
itself refers to a package name, and an external, applicable to
type or package references in the source code.
I imagine, only the external definition has to apply the second
paragraph requiring unique visibility, whereas internal references
to PackageName should be unaffected by this addition.

*Perhaps*, the phrase "If Q does not name an observable package"
intends to override the normal interpretation of package names, to
require only observability, not unique visibility, but this doesn't
work if first name resolution is obliged to check unique visibility
and possibly fail compilation.

Now correcting JLS in its current form will be quite tedious, like:
"within a package that is identified by the name Q, by applying
6.5.3 recursively while ignoring any requirement of unique visibility".
Yikes.

am I missing anything?
Stephan

Ceterum censeo ...
I'm really looking forward to the day, when JLS is refactored to
specify the language with no parent-sub package relation whatsoever,
leaving it entirely to any host system, to use prefixes of package
names for grouping stuff in containers like folders of a file system.
Wouldn't that make for a much cleaner specification?

OTOH, wherever JLS and compiler messages surface the concept of
a package "hierarchy", it will influence user expectations: Having
learned about package hierarchies users may likely expect that
exporting package "p1.p2" will also make "p1.p2.p3" accessible
just like "p1.p2.MyClass".
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: package hierarchy?

Alex Buckley
The quote from 6.5.3.2 is incorrect -- the paragraph beginning "If Q
does not name ..." is deleted. We discussed this in May, where I
explained why the section is the way it is. See
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012779.html.

I have also explained that the meaning of the qualified package name
Q.Id is NOT specified in terms of the simple package name Q. See
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012488.html.
That's why there is no requirement in 6.5.3.2 that Q be uniquely
visible, only Q.Id.

Stepping back, you seem to have a concern that the spec no longer relies
on hierarchy to give meaning to packages yet continues to present
subpackages as a feature of the language; and you believe this is a
tension that will have deleterious effects on ordinary developers. I do
not believe it will, because ordinary developers have always understood
that a package-access type in package p1.p2 is NOT accessible from the
"related, but not really" package p1.p2.p3. In the modular world, I do
not believe that a developer who exports p1.p2 has any expectation that
p1.p2.p3 is exported too. We deliberately designed the syntax of exports
-- one package per 'exports', no wildcards, no duplicates -- to ensure
explicit, methodical enumeration of the packages which represent the
module's contract with the outside world.

Alex

On 7/17/2017 3:59 AM, Stephan Herrmann wrote:

> This continues a discussion we had in January, but still isn't
> fully resolved in JLS 2017-06-26:
>
> Does the parent-sub relation of packages bear any meaning
> from the JLS p.o.v.?
>
> On 2017-01-10 Alex conceded:
>    "... you can consider all packages as unrelated to each other."
>
> Still JLS 6.5.3.2 has this (my emphasis):
>
> "If a package name is of the form Q.Id, then Q must also be a package name.
>   The package name Q.Id names a package that is the member named Id
>   *within the package named by Q*.
>   If Q does not name an observable package (§7.4.3), or Id is not the
> simple name
>   of an observable subpackage of that package, then a compile-time error
> occurs.
>
>   If Q.Id does not name a package that is uniquely visible to the current
>   module (§7.4.3), then a compile-time error occurs."
>
> Now, what's the meaning of "the package named by Q"?
>
> Technically, we need to consider Q as a package name, whose meaning
> is determined by 6.5.3.1 or 6.5.3.2.
> This inevitably implies that Q must be uniquely visible.
>
> In the end, this requires, e.g., that package "java" be uniquely visible in
> every Java 9 program. Or: every Java 9 program (even JDK itself) is
> illegal.
>
>
>
> I *imagine*, the spec authors intended two different definitions of
> PackageName: an internal definition that is applied whenever JLS
> itself refers to a package name, and an external, applicable to
> type or package references in the source code.
> I imagine, only the external definition has to apply the second
> paragraph requiring unique visibility, whereas internal references
> to PackageName should be unaffected by this addition.
>
> *Perhaps*, the phrase "If Q does not name an observable package"
> intends to override the normal interpretation of package names, to
> require only observability, not unique visibility, but this doesn't
> work if first name resolution is obliged to check unique visibility
> and possibly fail compilation.
>
> Now correcting JLS in its current form will be quite tedious, like:
> "within a package that is identified by the name Q, by applying
> 6.5.3 recursively while ignoring any requirement of unique visibility".
> Yikes.
>
> am I missing anything?
> Stephan
>
> Ceterum censeo ...
> I'm really looking forward to the day, when JLS is refactored to
> specify the language with no parent-sub package relation whatsoever,
> leaving it entirely to any host system, to use prefixes of package
> names for grouping stuff in containers like folders of a file system.
> Wouldn't that make for a much cleaner specification?
>
> OTOH, wherever JLS and compiler messages surface the concept of
> a package "hierarchy", it will influence user expectations: Having
> learned about package hierarchies users may likely expect that
> exporting package "p1.p2" will also make "p1.p2.p3" accessible
> just like "p1.p2.MyClass".
Loading...