Project class >> #makeExistingView:project:projectsToBeDeleted:

> Normally I would, but this is more complicated than a simple moving of a method. I don't know the how this method's used so I've assumed that proj is a Project-like thing, and there are no tests for this code (that I can see).
>
> So I thought I'd ask before telling... this time :)
>
> frank
>
> On 03 Jun 2013, at 19:27, Nicolas Cellier <[hidden email]> wrote:
>
> > tell don't ask ;)
> >
> >
> > 2013/6/3 Frank Shearar <[hidden email]>
> > I just found this method. It contains this snippet:
> >
> > Smalltalk isMorphic ifTrue: [
> >     proj createViewIfAppropriate.
> > ] ifFalse: [
> >     ChangeSorter allChangeSets add: proj changeSet.
> >     ProjectView openAndEnter: proj.
> >     "Note: in MVC we get no further than the above"
> > ].
> >
> > Wouldn't that be better written by implementing
> >
> > MVCProject >> #createViewIfAppropriate
> >     ChangeSorter allChangeSets add: proj changeSet.
> >     ProjectView openAndEnter: proj.
> >
> > and ripping out the #isMorphic call?
> >
> > frank
> >
> >
> >

> >From the point of view of getting rid of #isMorphic, you are right that it
> would be better to implement MVCProject>>createViewIfAppropriate, as well
> as this:
>
> Project>>createViewIfAppropriate
>         ^self subclassResponsibility
>
> I'm not sure if the change carries its weight though. This does not seem like
> something that needs to be part of the Project API, and refactoring it may make
> it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted:
> in the event that someone tries to use it in MVC.
>
> This seems to be an Etoys method in which the #isMorphic test serves to document
> a bad thing that is going to happen if you were to use it in MVC (if you need
> to create the new view, you will enter that view and never execute the remainder
> of the method).
>
> The call to #isMorphic may be bad but I think that adding unnecessary vocabulary
> to Project is undesirable, so in balance I would vote to not change the method.
>
> I do suspect that a better refactoring is possible, but I don't know enough about
> how the project loading should work to suggest something.

> Dave
>
>
> On Mon, Jun 03, 2013 at 11:42:50PM +0100, Frank Shearar wrote:
>> Normally I would, but this is more complicated than a simple moving of a method. I don't know the how this method's used so I've assumed that proj is a Project-like thing, and there are no tests for this code (that I can see).
>>
>> So I thought I'd ask before telling... this time :)
>>
>> frank
>>
>> On 03 Jun 2013, at 19:27, Nicolas Cellier <[hidden email]> wrote:
>>
>> > tell don't ask ;)
>> >
>> >
>> > 2013/6/3 Frank Shearar <[hidden email]>
>> > I just found this method. It contains this snippet:
>> >
>> > Smalltalk isMorphic ifTrue: [
>> >     proj createViewIfAppropriate.
>> > ] ifFalse: [
>> >     ChangeSorter allChangeSets add: proj changeSet.
>> >     ProjectView openAndEnter: proj.
>> >     "Note: in MVC we get no further than the above"
>> > ].
>> >
>> > Wouldn't that be better written by implementing
>> >
>> > MVCProject >> #createViewIfAppropriate
>> >     ChangeSorter allChangeSets add: proj changeSet.
>> >     ProjectView openAndEnter: proj.
>> >
>> > and ripping out the #isMorphic call?
>> >
>> > frank
>> >
>> >
>> >
>
>>
>
>

> On 4 June 2013 00:52, David T. Lewis <[hidden email]> wrote:
> > >From the point of view of getting rid of #isMorphic, you are right that it
> > would be better to implement MVCProject>>createViewIfAppropriate, as well
> > as this:
> >
> > Project>>createViewIfAppropriate
> >         ^self subclassResponsibility
> >
> > I'm not sure if the change carries its weight though. This does not seem like
> > something that needs to be part of the Project API, and refactoring it may make
> > it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted:
> > in the event that someone tries to use it in MVC.
> >
> > This seems to be an Etoys method in which the #isMorphic test serves to document
> > a bad thing that is going to happen if you were to use it in MVC (if you need
> > to create the new view, you will enter that view and never execute the remainder
> > of the method).
> >
> > The call to #isMorphic may be bad but I think that adding unnecessary vocabulary
> > to Project is undesirable, so in balance I would vote to not change the method.
> >
> > I do suspect that a better refactoring is possible, but I don't know enough about
> > how the project loading should work to suggest something.
>
> Dang. I agree with you, and am keen to hear other proposals. I dislike
> the #isMorphic call, but mainly I'm trying to lose the ProjectView
> reference. This is one of, if I recall correctly, two references to
> the ST80 package in the base image.
>

> On Tue, Jun 04, 2013 at 07:27:02AM +0100, Frank Shearar wrote:
>> On 4 June 2013 00:52, David T. Lewis <[hidden email]> wrote:
>> > >From the point of view of getting rid of #isMorphic, you are right that it
>> > would be better to implement MVCProject>>createViewIfAppropriate, as well
>> > as this:
>> >
>> > Project>>createViewIfAppropriate
>> >         ^self subclassResponsibility
>> >
>> > I'm not sure if the change carries its weight though. This does not seem like
>> > something that needs to be part of the Project API, and refactoring it may make
>> > it harder to understand what happens in #makeExistingView:project:projectsToBeDeleted:
>> > in the event that someone tries to use it in MVC.
>> >
>> > This seems to be an Etoys method in which the #isMorphic test serves to document
>> > a bad thing that is going to happen if you were to use it in MVC (if you need
>> > to create the new view, you will enter that view and never execute the remainder
>> > of the method).
>> >
>> > The call to #isMorphic may be bad but I think that adding unnecessary vocabulary
>> > to Project is undesirable, so in balance I would vote to not change the method.
>> >
>> > I do suspect that a better refactoring is possible, but I don't know enough about
>> > how the project loading should work to suggest something.
>>
>> Dang. I agree with you, and am keen to hear other proposals. I dislike
>> the #isMorphic call, but mainly I'm trying to lose the ProjectView
>> reference. This is one of, if I recall correctly, two references to
>> the ST80 package in the base image.
>>
>
> Ah yes, now I see the problem. You're right, this needs to be fixed.
> I think that Project>>openProject: does what we want here.
>
> MVC is supposed to be completely unloadable/reloadable. What is the other
> reference to ST80 in the base image?

> On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
>> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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?

> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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.
>

> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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.

> On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
>> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
>> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
>> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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.

> On 5 June 2013 00:02, David T. Lewis <[hidden email]> wrote:
> > On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
> >> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
> >> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
> >> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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.

> On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
>> On 5 June 2013 00:02, David T. Lewis <[hidden email]> wrote:
>> > On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
>> >> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
>> >> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
>> >> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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?

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

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

> On 5 June 2013 13:20, David T. Lewis <[hidden email]> wrote:
>> On Wed, Jun 05, 2013 at 07:44:15AM +0100, Frank Shearar wrote:
>>> On 5 June 2013 00:02, David T. Lewis <[hidden email]> wrote:
>>> > On Tue, Jun 04, 2013 at 01:20:36PM +0100, Frank Shearar wrote:
>>> >> On 4 June 2013 13:06, David T. Lewis <[hidden email]> wrote:
>>> >> > On Tue, Jun 04, 2013 at 12:09:59PM +0100, Frank Shearar wrote:
>>> >> >> On 4 June 2013 12:05, David T. Lewis <[hidden email]> 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
>>> >
>>> >
>>

> On 5 June 2013 13:35, Frank Shearar <[hidden email]> wrote:
> > On 5 June 2013 13:20, David T. Lewis <[hidden email]> wrote:
> >>
> >> 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

> On Sun, Jun 30, 2013 at 11:42:01AM +0100, Frank Shearar wrote:
>> On 5 June 2013 13:35, Frank Shearar <[hidden email]> wrote:
>> > On 5 June 2013 13:20, David T. Lewis <[hidden email]> wrote:
>> >>
>> >> 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
>
> That seems like a reasonable approach. I think it would be important to
> take the same approach for both MVC and Morphic, so we could eventually
> have for MVC:
>
>   ST80-Controllers    \
>   ST80-Editors         \
>    ...                  >  - current ST80 package
>   ST80-Views           /
>   ST80-ToolBuilder    /
>   ST80Tools                - new ST80Tools package
>
> And for Morphic:
>
>   Morphic-Balloon     \
>   Morphic-Basic        \
>    ...                  >  - current Morphic package
>   Morphic-Worlds       /
>   Morphic-ToolBuilder /
>   MorphicTests             - current MorphicTests package
>   MorphicTools             - new MorphicTools package
>
> Is that right?