[squeak-dev] modularity goals (was: The Trunk: ToolBuilderTests-fbs.1.mcz)

Chris Muller asqueaker at gmail.com
Mon Dec 9 20:50:05 UTC 2013


>> There has been a great effort headed up by Frank to organize behaviors
>> into a hierarchy of packages with no cyclic dependencies.  This is a
>> great goal and great effort.
>>
>> But the introduction of this new package (with just two classes)
>> prompts a need to understand what _all_ the goals are for this
>> process.  Certainly, everyone agrees we want no cyclic dependencies
>> between packages.
>>
>> But this extraction doesn't help that.  Nothing will ever depend on
>> ToolBuilderTests, so how does this new leaf of the package-dependency
>> hierarchy, justify its existence in cyberspace?
>
> ToolBuilder no longer depends on SUnit. I fail to see how that's bad.

Not "bad" -- where did you get that?  Frank, I hope you don't feel
badgered, my only goal in stimulating these discussions is to
establish and maintain consensus about _what_ we want from the
modularization effort, and _why_ we want it.  To wit:

  - What we want:  A coherent hierarchy of behaviors with no cycles
between the nodes of the hierarchy.
  - Why we want it (1):  Coherence and Reusability.  A system with
well-defined package responsibilities expresses its structure merely
by the delineation of behaviors chosen by the developers.
  - Why we want it (2):  Configuration.  Via the following manner:  1)
start with some "Core" (Kernel + Collections + Exceptions + a few
others), 2) ADD packages to it necessary for some vertical purpose.

  - ??  (anything else?)

I started this thread because this new package does not seem to
contribute toward the first three bullets.  That does not mean it
should not be done, only that as a community to give it due
consideration.

>> Getting SUnit completely out of the image will mean ALL packages must
>> be split between their "-Kernel" and "-Tests" components.  Is that the
>> plan?
>
> I suppose eventually, yes. What's the point of unloading ST80 but leaving
> its tests in Tests?

I never suggested anything close to that..

>> I'm not necessarily against it -- I'm just having trouble articulating
>> what's wrong with co-location of a package's tests, with the package
>> itself, and it depending on SUnit vs. not.  SUnit is not that big and
>> depends on nothing but Core.
>
> I do not understand why a GUI specification should depend on a test
> framework.

So one can run its tests and know that the GUI-specification is
performing correctly, of course!  :)  Before deploying an image to
production is a good time to run tests.

To which you might respond:  "So then load up SUnit and
ToolBuilderTests and run them, silly!"  But that's beside the question
of asking, "_why_ were they separated in the first place?"  Because it
wasn't for module reusability, nor to eliminate any dependency
cycles..

It keeps sounding like it's about "size".  That, even though we cannot
achieve optimal size, we can get "closer" to optimal with more and
smaller packages..  But at the cost of a more soupy package
hierarchy..

But you've said a few times it's not about size so...?


More information about the Squeak-dev mailing list