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

Frank Shearar frank.shearar at gmail.com
Mon Dec 9 22:17:24 UTC 2013


On 9 December 2013 20:50, Chris Muller <asqueaker at gmail.com> wrote:
>>> 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?

I should have added - its status as a leaf is irrelevant to the topic,
because the most visible packages - applications like Magma, EToys,
and so on - will usually be leaves.

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

Bullet point 1 (coherence) contains an implicit principle - the
principle of least authority^Wdependency. That is, a package should
depend on other packages as little as possible. ToolBuilder doesn't
use SUnit, doesn't need SUnit, so shouldn't have a dependency on SUnit
forced just because of its tests.

>>> 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 was trying to answer your question about whether to bundle tests
together with the package. In this case, my point is, like I said to
David, that the tests of a package being in the Tests package means
that those packages can't be properly unloaded.

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

:) But of course you don't mean that the _specs_themselves_ should
depend on TestCase. But if you bundle the thing-under-test together
with the tests, you can't separate the two.

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

In this particular case, it was for aesthetic reasons. It makes no
sense to me for ToolBuilder to depend on SUnit. SUnit contributes
nothing towards ToolBuilder's _functionality_. We already have a load
of Test packages - CollectionsTests, MorphicTests, HelpSystem-Tests,
ToolsTests, etc., so it seemed a no-brainer to add a ToolBuilderTests.

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

It's about grouping things together things that belong together. Now,
I realise that Foo's tests belong with Foo, and they do, in a sense...
I suppose mainly I care very much about _these_ dependencies because
they're very low in the stack. If you wrote a Squeak application that
bundled its tests in the same package, well, that's OK. But it's OK
because its effect is limited to the application, not the entire
system.

I do appreciate your point that an excessive number of fine-grained
packages would be daunting to manage. I try not to create new
packages. In this case, it seemed like the natural thing to do.

frank


More information about the Squeak-dev mailing list