On 12 August 2013 20:39, Chris Muller <asqueaker at gmail.com> wrote:
>>> * I want Utilities to die. It's a mess of mixed responsibilities. Even
>>> were that all cleaned up, it'd be a mess of mixed responsibilities
>>> delegated to better suited places. It's Bad(tm) for modularity:
>>> Utilities >> #updateFromServer makes System depend on
>>> MonticelloConfiguration, which is already dependent on System.
>>> Breaking that cycle is the whole point of this commit.
>>>
>>> * With MCMcmUpdater >> #updateFromServer we concentrate updating in one place.
>>
>> Maybe we need some high-level package then that can easily depend on all the stuff. MCMcmUpdater is just the mechanism, but the intent is something like "Squeak updateFromServer" (or even just "Squeak update"). Utilities used to be that place. I'm fine with something different, but having a gazillion single-purpose classes for such high-level operations seems to make things harder on users, not simpler.
>>
>> Discussion welcome, of course :)
>
> +1.  For both actually -- We want the system packages to be more
> modularized, but not have to remember two things instead of just one,
> every time we want to make use of a "system" service.

Despite my monomania, I agree. In this particular case there is only
one thing to remember - update - but for sure, higher level packages
stitch together smaller, specific, goals into some overarching
concern.

> The facade would reside in some pretty high-level package, but which
> one?  A reason to be interested in starting to think about our package
> hierarchy..
>
> As for the facades name, hm.  We do already have "Smalltalk"...?

Certainly `Smalltalk updateFromTrunk` has a nice ring to it.

frank