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.

> 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.

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

> So yes, there is indeed something wrong with MonticelloConfiguration
> depending on System.
>
> If you want a modular system, then you want to be able to define a
> core on which you put some other bits, on which you build some more
> bits, until eventually you supply a user interface (graphical or
> otherwise) for a person to use. Every cyclic dependency can only occur
> within one conceptual layer, and we have _so many_ cyclic
> dependencies, we effectively have a one-layer system.

I'm all for getting rid of the cycles.  Perhaps it would help if we
organized our existing list of packages into a hierarchy of
dependency, just "on paper" (e.g., in a new e-mail thread) and see if
we can identify what we think the overall responsibilities of each
package.  To have a coherent picture of the capabilities of each
"module" and, therefore, its position in the dependency tree.

> frank
>
> On 25 July 2013 16:44, Chris Muller <asqueaker at gmail.com> wrote:
>> So, you want to move something "back" to Exceptions and will mean it's
>> the only class in that package, but it will remove one of several
>> dependencies on System -- as if there's something wrong with
>> MonticelloConfigurations depending on System..?
>>
>> I must admit, I'm really confused about your motivations, Frank.
>>
>> On Wed, Jul 24, 2013 at 5:35 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
>>> On 23 July 2013 10:46,  <commits at source.squeak.org> wrote:
>>>> Frank Shearar uploaded a new version of Exceptions to project The Trunk:
>>>> http://source.squeak.org/trunk/Exceptions-fbs.48.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Exceptions-fbs.48
>>>> Author: fbs
>>>> Time: 23 July 2013, 10:43:57.584 am
>>>> UUID: ae58a39c-c2b3-f64f-8e96-f1e5b5d238e4
>>>> Ancestors: Exceptions-fbs.47
>>>>
>>>> Move Exceptions close to where they're used, rather than collecting them together just because they're Exceptions.
>>>>
>>>> =============== Diff against Exceptions-fbs.47 ===============
>>>>
>>>> Item was removed:
>>>> - Notification subclass: #ProgressNotification
>>>> -       instanceVariableNames: 'amount done extra'
>>>> -       classVariableNames: ''
>>>> -       poolDictionaries: ''
>>>> -       category: 'Exceptions-Kernel'!
>>>> -
>>>> - !ProgressNotification commentStamp: '<historical>' prior: 0!
>>>> - Used to signal progress without requiring a specific receiver to notify. Caller/callee convention could be to simply count the number of signals caught or to pass more substantive information with #signal:.!
>>>
>>> I'm seriously thinking of moving ProgressNotification back to
>>> Exceptions. It would be the only class in that package, but it would
>>> mean that MonticelloConfigurations would depend on Exceptions, not
>>> System. There are other things causing MonticelloConfigurations ->
>>> System, but this would remove one of them at least.
>>>
>>> frank
>>>
>>