On 5 June 2013 13:20, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
On 5 June 2013 00:02, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
On 4 June 2013 13:06, David T. Lewis lewis@mail.msen.com wrote:
On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
On 4 June 2013 12:05, David T. Lewis lewis@mail.msen.com wrote: > > MVC is supposed to be completely unloadable/reloadable. What is the other > reference to ST80 in the base image?
Tools has extensions to ParagraphEditor, ScreenController and StringHolderView.
I don't see the dependencies ... what am I missing?
The *Tools method categories cause a dependency from Tools -> ST80 because Tools requires those classes to exist.
You can track the dependencies through the DependencyBrowser in the Apps menu off TheWorldMainDockingBar.
I don't think I trust what the DependencyBrowser is telling us here. The methods causing dependencies seem to be either methods that have matching implementations in both Morphic and MVC, or methods that are referenced from MVC menu picks. I don't think the dependencies are real.
I disagree. Tools is extending classes in ST80. Were you to unload ST80, you would rip out part of Tools.
You would be removing the '*Tools' extensions in the ST80 package, but not anything that is directly part of the main 'Tools' package, right?
Yes. Tools would still work, providing Monticello didn't barf on loading.
Or put it another way: take an image, unload ST80 and Tools, and then load Tools. I predict that loading Tools would fail, because it would say "I'm sorry Dave, I can't let you do that. I don't know about the classes ParagraphEditor, ScreenController and StringHolderView."
I understand what you mean now. Yes you are right. ST80 can be unloaded and reloaded, but there are methods categorized as '*Tools' in some ST80 classes, and presumably these would be a problem for loading Tools if those ST80 classes were not already present. Or maybe the Monticello loader knows how to handle this already?
I don't know. I'd run a test, but I'm running at capacity at the moment.
I don't know if making a package like Tools fully independent of Morphic and ST80 is a practical goal. There are also extensive dependencies of Tools on Morphic. If the idea is to make Tools fully independent of the Morphic/MVC user interfaces, it looks to me like this would be a big challenge.
I think it should be. Specifically, Tools should only depend on ToolBuilder-Kernel. Most (but by no means all) of those Morphic dependencies stem from FileList2. I've asked about this class before, and I only got one reply: Stéphane Rollandin says that he subclasses it in muO, but that "I don't think it will be a huge problem for me if you nuke it though so AFAIC do as you want." Losing FileList2 would also remove the Tools -> MorphicExtras dependency, for extra good.
Actually, I'd phrase that even stronger: I don't think _anything_ (except maybe Etoys, but that's a special case) should have a dependency on Morphic or ST80, except as mediated through ToolBuilder-Kernel. That would make the rest of the image UI agnostic, which is a fine place to be!
frank
Dave
frank
So... I think that MVC remains safely unloadable and reloadable. The next challenge is to get to the point where we can say the same about Morphic :)
Dave