On 5 June 2013 13:20, David T. Lewis <lewis at 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 at 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 at 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 at 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
>> >
>> >
>