[RFC] Morphic-FileList recategorizing

For reloadable MVC, I am looking at MVC dependencies in other packages.
The classes in Morphic-FileList that all seem to belong elsewhere. It
looks to me like the following package changes would make sense, but
I'd like to ask for feedback before moving any of them.

Proposed moves from Morphic-FileList:

Move two MVC views to ST80
  move ModalSystemWindowView to package ST80-Views
  move PluggableFileListView to package ST80-Pluggable View

Move three file list models that may be used in either MVC or Morphic
  move FileList to package Tools-FileList
  move FileList2 to package Tools-FileList
  move PluggableFileList to package Tools-FileList

Two file selection menus that many be used in either MVC or Morphic
  move StandardFileMenu to package Tools-Menus
  move StandardFileMenuResult to package Tools-Menus

Does the above look right? And can anyone think of anything that
would be broken by such a packaging change?

Thanks,
Dave

FYI, I made the following changes in trunk:

  Move FileList from Morphic-FileList to Tools-FileList
  Move FileList2  from Morphic-FileList to Tools-FileList
  Move FileLPluggableFileListst2  from Morphic-FileList to Tools-FileList
  Move StandardFileMenuResult  from Morphic-FileList to Tools-Menus
  Remove package category from Morphic-FileList

The resulting diff messages are rather large, so probably will not
appear in the usual mailing list updates.

Sorry for spamming the list with a lot of small updates today, but
it was a snow day here in Michigan so I took the day off, brewed up
some coffee and went to work on MVC reloadability. One more snowstorm
should easily be enough to finish the job :)

Dave

On Tue, Feb 02, 2010 at 07:38:32AM -0500, David T. Lewis wrote:

David T. Lewis wrote:
> Sorry for spamming the list with a lot of small updates today, but
> it was a snow day here in Michigan so I took the day off, brewed up
> some coffee and went to work on MVC reloadability. One more snowstorm
> should easily be enough to finish the job :)

Hey, more power to you! (let's hope the snow keeps up for just a little
while longer :) I had one funny effect when I updated which was that
suddenly tons of transcripts popped open due to the order in which some
packages were loaded. I issued a config map to bring the packages in the
right order and prevent this issue.

Cheers,
   - Andreas

On Wed, Feb 10, 2010 at 08:37:42PM -0800, Andreas Raab wrote:
Andreas,
Thanks for fixing this.

On a related topic, I'm not sure how ToolBuilder-MVC (and ToolBuilder-Morphic)
should be handled. I've been treating package ST80 as equivalent to MVC
which would suggest changing ToolBuilder-MVC to ST80-Toolbuilder if the
primary goal is to have reloadable MVC and Morphic. However, ToolBuilder
is maintained as a package in its own right, so the current package naming
is important.

I'm inclined to think that "unload MVC" should mean "unload all of ST80
plus all of ToolBuilder-MVC plus all methods in other packages in method
categories *ST80-*". Does that sound right?

FWIW unloading and reloading MVC does work, but still requires recompiling
the sources after reloading the ST80 package. The remaining work is just
a matter of cleaning up some references to ST80 classes from classes outside
of the package, which leaves only about 30 remaining issues if I'm counting
correctly (a very short list compared to where we started).

Dave

David T. Lewis wrote:
> On a related topic, I'm not sure how ToolBuilder-MVC (and ToolBuilder-Morphic)
> should be handled. I've been treating package ST80 as equivalent to MVC
> which would suggest changing ToolBuilder-MVC to ST80-Toolbuilder if the
> primary goal is to have reloadable MVC and Morphic. However, ToolBuilder
> is maintained as a package in its own right, so the current package naming
> is important.

The reason ToolBuilder is structured the way it is is mostly to avoid
having additional dependencies. Logically, ToolBuilder-MVC depends on
*both* ToolBuilder as well as MVC being present. One could repackage
this into ST80-ToolBuilder but that would make ST80 dependent on
ToolBuilder which is a bad trade in my understanding. I'd like to have
the option to say "I don't need no stinkin' tools and I don't need no
stinkin' ToolBuilder either".

> I'm inclined to think that "unload MVC" should mean "unload all of ST80
> plus all of ToolBuilder-MVC plus all methods in other packages in method
> categories *ST80-*". Does that sound right?

Absolutely. If we had better modeling of package dependencies then
obviously anything that requires MVC needs to be unloaded before MVC can
be unloaded itself (coincidentally, this is one of the issues I have
with Metacello: it does not support unloading).

> FWIW unloading and reloading MVC does work, but still requires recompiling
> the sources after reloading the ST80 package. The remaining work is just
> a matter of cleaning up some references to ST80 classes from classes outside
> of the package, which leaves only about 30 remaining issues if I'm counting
> correctly (a very short list compared to where we started).

Wow! That is *great* news.

Cheers,
   - Andreas

On 2/10/10 9:42 PM, "David T. Lewis" <[hidden email]> wrote:

> it was a snow day here in Michigan
Wish trade some of snow for 35 C ?

Sorry, I can't resist :=)