Well, I finally put Bottom Feeder back together on ye ol' PowerBook. And behold there's a new posting tool. All Wysiwyg'ed out. Fun.
Last week, I factored a large chunk of stuff out of rather overburdened Package. As I am wont to make "modules" out of my packags, I did the usual, made a new namespace for the new package, and moved the moved behavior into that namespace. I'm still not sure I've recovered from the experience. I've grown so used to the various code modifying menu options being refactorings (i.e. things still work after the change is is applied), that I forget that "Move to Namespace" is not one. Since the bindings reference the actual objects, though you've changed the path, your current image will continue to work fine. But if you rebuild your image, then stuff is now broken.
I thought some about this whole namespace imports thing after the experience. What we've typically done is created a namespace per package. For imports, we've always done the "import namespace into container" option. So we end up with imports that look like some subset of our package prereq tree. After thinking about it a bit, I decided that managing imports reminds me of managing header file include lines. I maintain some moderatly sized C code. I hate managing the includes. Something doesn't compile. So you figure out what to include. Eventually you get it to compile. It may be because you directly included what you need, or maybe indirectly. The weird thing is how this stuff just clumps up during the development cycle of a project. Header files that get added and then due to changes are no longer needed, stick around. Because of changes in recursively included stuff, one day, stuff just breaks. I'm used to this in the C world. I realized the other day, that while the boundaries of scope are arbitrary rather than file based, you still end up with the same mess.
I don't have a solution. Maybe there isn't one. Maybe this is just the necessary downside of having an environment with multiple compilation scopes. Are there any niche languages that take an "out of the box" approach to this problem. I've toyed with taking one of these "modules" we have and doing away with imports and just using dotted references to see how miserable that would be.