On 25 July 2013 19:40, Chris Muller ma.chris.m@gmail.com wrote:

On Thu, Jul 25, 2013 at 12:50 PM, Frank Shearar frank.shearar@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