Alternatives for naming automatic modules, and a proposal (#AutomaticModuleNames)
brianf at infinity.nu
Wed Apr 26 17:27:30 UTC 2017
On Wed, Apr 26, 2017 at 12:27 PM, <mark.reinhold at oracle.com> wrote:
> If one of those automatic modules is modularized later on, and given a
> different name, then how is having to fix that materially different from
> having to fix code that was using a package that's no longer exported?
> If anything it might actually be easier to cope with a module-name
> change, since all you have to do is edit a `requires` directive; code
> that refers to a package that's now encapsulated might require a
> non-trivial rewrite.
> I think I need to reconsider my previous conclusion that explicit modules
> that depend upon automatic modules should never be published for broad
> use . Sure, they have unstable names and unstable APIs but if, as you
> say, people are generally used to fixing minor problems when they upgrade
> then this instability may well be tolerable -- especially since it would
> allow maintainers to modularize whenever they want to rather than only
> after all of their dependencies have been modularized.
One is an edge case, the other is the normal case. Just because _some_
people will have to fix their dependencies, doesn't mean we should choose a
path that forces _all_ users to deal with names changing all over the place.
More information about the jigsaw-dev