On Sat, Dec 07, 2013 at 07:23:12PM +0000, Frank Shearar wrote:
> At the moment, "UIManager default" delegates to Project current
> uiManager, which looks like this:
> 
> Project >> uiManager
>     "Answer the manager that provides user interface services for this project "
>     ^ uiManager
>         ifNil: [uiManager := Smalltalk
>             at: #UIManager
>             ifPresent: [:mgr | uiManager := mgr getDefault]]
> 
> I'm not sure why we do this. I guess it's to let different Projects
> use their own UIManager.

Right. A project as a UI manager. In particular, a MorphicProject
has a MorphicUIManager, an MVCProject has an MVCUIManager, and a
SeasideProject would have a SeasideUIManager. This needs to always
work whenever transitioning between different projects, because it
is generally not possible to open a debugger if something goes wrong.

> What I don't like is that this makes
> ToolBuilder-Kernel depend on System (which depends on
> ToolBuilder-Kernel). If I made UIManager default _not_ delegate to
> Project, I could break this dependency. (ToolBuilder would then be
> conceptually lower level than System.)
> 
> For instance,
> 
> UIManager class >> #default
>     ^ Default ifNil: [Default := self getDefault].

That will not work. It will answer an instance of whatever flavor
of UI manager was in effect at the time that you cached it.

> 
> Another option would be to push Project into Kernel, but I'm reluctant
> to do that.
> 
> Thoughts? Alternatives?
> 

Much of what you see is the result of work that I did under Andreas'
guidance to make MVC fully unloadable and reloadable. The corresponding
work to make Morphic unloadable and reloadable has not been done, and
was not possible at that time because MVC was too badly broken. Since
then, MVC as been restored to a state in which it can be used (although
not without problems), so it would be reasonable at this time to consider
making Morphic unloadable and reloadable. That will require significant
work, but the end result would be a huge step forward in modularity.

Aside from that, I have no preference with respect to package refactorings.
If you do change it, test to make sure that you can move back and forth
between existing Morphic and MCV projects (i.e. projects that you created
prior to the change), and also that you can open new Morphic and MVC
projects, and enter and leave them without error.

By the way, the "Smalltalk at: #UIManager ifPresent: [:mgr .... " idiom
is there to break a package dependency. It's not pretty but it works,
so it's something to keep in mind if you find yourself moving a class
to a place that it may not belong just to resolve a reference in a class
side utility method.

Dave