Yeah, that was my original proposal (seems like years ago now :^), but
it means that you can never escape from your mistakes.
As a newbie, you create module X containing your code in package X. But
you have a dependency on package Y, so, following the traditional
keep-adding-to-the-classpath-till-it-works model, you throw in package
Y. But, argh, Y depends on Z, so you throw that in as well. Being a
newbie, you export everything to keep it simple.
Sometime later you realize it was a mistake to export Y and Z: your code
didn't actually depend on Z, nor did it expose Y. And the version of Y
that you want to use now is available in a shiny new module.
So you refactor to remove packages Y and Z and import Y instead.
But for compatibility, you are forced to also:
1. Import Z.
2. Re-export both Y and Z.
Ugly. Far worse though: it binds your importers both to the version of Y
that you depend on (but don't expose in your code), and the version of Z
that you don't depend on at all!
And all of this is a direct consequence of import-by-module. With
import-by-package, this issue just... vanishes.
// Bryan
Adrian Brock wrote:
On Thu, 2008-06-12 at 17:13 -0700, Bryan Atsatt wrote:
Really, I just want to make it possible for a module developer to be in
a position to "know" that splitting one module into multiple modules
will not break existing importers. I'm quite open to other solutions, as
long as they are reasonable.
But can't that also be achieved with the old module re-exporting the
split out module for backwards compatibility purposes?
