Refactorability proposal...

[Bryan Atsatt]

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?
>