On 5 June 2013 13:35, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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.

One way to break this Tools->ST80 dependency is adding a new package,
ST80Tools. This would contain the ST80 specific extensions. It makes
things slightly more complicated for loading/unloading MVC, in that
"unload" would mean "unload ST80 and any of its associated packages
(currently just ST80Tools)", and similarly for loading.

frank

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