Clean-up Debugger code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Clean-up Debugger code

marcel.taeumel
Hi, there!

Projects (partially) govern the way processes are used in the user interface.

Wouldn't it make sense to move the *Morphic and *ST80 extensions from the Debugger class to MorphicProject resp. MVCProject?

For example, there is already the call "Project resumeProcess: processToResume" in Debugger >> #morphicResumeProcess:.

The debugger is good in stepping a suspended process but the circumstances of that particular process is known only to the current project.

This would clean up some Debugger code. :-)

Best,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Clean-up Debugger code

David T. Lewis
On Wed, Mar 30, 2016 at 11:45:28PM -0700, marcel.taeumel wrote:

> Hi, there!
>
> Projects (partially) govern the way processes are used in the user
> interface.
>
> Wouldn't it make sense to move the *Morphic and *ST80 extensions from the
> Debugger class to MorphicProject resp. MVCProject?
>
> For example, there is already the call "Project resumeProcess:
> processToResume" in Debugger >> #morphicResumeProcess:.
>
> The debugger is good in stepping a suspended process but the circumstances
> of that particular process is known only to the current project.
>
> This would clean up some Debugger code. :-)
>

Hi Marcel,

Yes I think this would be a good thing to do. The #morphicResumeProcess:
and #mvcResumeProcess methods are still in Debugger, but the only
reason for this is I was not able to find a clean way to move them
to MorphicProject and MVCProject. But my interest at that time was
mainly to make MVC (and hopefully Morphic) be unloadable and reloadable,
and maybe I just did not try hard enough to get the refactoring right
in this case.

So if you can make it work, that would be great :-)

Dave