On 25 July 2013 19:40, Chris Muller <ma.chris.m at gmail.com> wrote:
> On Thu, Jul 25, 2013 at 12:50 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
>> Cyclic dependencies ruin any possibility of being able to build up a
>> system from some small core.
>
> Yes, I understand and agree with that.
>
>> So you have MonticelloConfigurations. It depends on System, which
>> depends on MonticelloConfigurations. In turn, System depends on
>> Kernel, which depends on System, which depends on Collections, which
>> depends on Kernel, which depends on Graphics, which depends on System,
>> which depends on oh I'm sure you get the idea already.
>
> System should not depend on MonticelloConfigurations.

I suppose you see System as being a fairly low-level package. It
_should_ be, but at the moment it's not. It kind've stretches from low
level stuff all the way up the notional stack. It supplies hook points
for services, installs code, supplies the bulk of the reflective
machinery, supplies change notification, handles out-of-image storage,
...

But that aside, I don't really care deeply about which dependency
goes, as long as one of them does.

So if we want to break System's dependency on
MonticelloConfigurations, the lowest hanging fruit is moving "update
from trunk" code out of Utilities. I've some local changes that move
Utilities >> #updateFromServer and #updateFromRepositories to
MCMcmUpdater, leaving a deprecated stub in Utilities.

The other strands of this dependency stem from AutoStart class (a
Preference lets you automatically check for updates on image startup),
some add-updates-to-menus stuff, and SmalltalkImage >>
#unloadAllKnownPackages.

The AutoStart looks like the most difficult to separate.

SmalltalkImage >> #unloadAllKnownPackages refers directly to
MCMcmUpdater. This method _could_ move out of System. Not hugely keen
on that idea. We could lose the method entirely, but I don't much care
for that either.

>> The inter-package dependencies, which enormously simpler than they
>> were, are simply a nearly impenetrable mess. MonticelloConfiguration
>> has exactly zero reason to depend on System (and hence on just about
>> the entire rest of the image), because it simply - or should simply -
>> describe a configuration of Monticello packages.
>
> Yes but there may be some utility behaviors like.. saving to a MC HTTP
> server which would require something out of System.

I was about to argue that you'd just need MC for that, but where would
you get the update repository information? From Preferences, of
course, in the System package.

> So, to me, it's fine for MonticelloConfigurations to depend on System,
> but not the other way around.

OK, fair enough. I view this entire modularity thing as a process.
I've almost certainly made a number of mistakes in how I'd cleaved out
the packages, so I expect a fair amount of to'ing and fro'ing on what
goes where. It's when we unload everything and start building things
back up that we'll figure out what _really_ belongs where.

frank