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

Eliot Miranda eliot.miranda at gmail.com
Mon Dec 9 23:54:43 UTC 2013


On Mon, Dec 9, 2013 at 3:37 PM, Chris Muller <asqueaker at gmail.com> wrote:

> I want you to know, several of my packages like Ma-Serialization and
> Magma DO separate out a "-Tests" package from the core functionality
> -- because they're biggish.  For me, it was only when the tests were
> so minor in size that I decided I didn't warrant the extra "line item"
> in the package list, file-directories, etc.
>
> > 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.
>
> I _am_ glad for what you said above.  We definitely agree it's a
> natural thing to do, if not always the threshold of when we should do
> it.  Not a big deal for "-Tests" packages.
>
> >> 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.
>
> This is why I said earlier that stripping was not being given due
> consideration.
>
> Shrinking/stripping activities are already a regular part of
> Configuration-for-deployment.
>
> Much less so for configuring a development image.  That's the time
> when I "want everything" and as few complications as possible to get
> there.
>
> I can relent for this "-Tests" idiom but, mark my words Frank, I'm
> watching you!  :)  If tiny new packages besides "-Tests" start
> appearing, we'll be having this conversation again.
>
> PS -- Since it was for aesthetic reasons, it would be better and more
> consistent if it were named "ToolBuilder-Tests" instead of
> "ToolBuilderTests".
>

Sure, but then Monticello forces you to have as many packages as there are
ToolBuilder-Foo thingies, right?  That's ok for ToolBuilder, but for Tools
it doesn't fly.  It forces
Tools-Deployment-Base, Tools-Deployment-Browser, Tools-Deployment-Debugger
et al so one can have Tools-Deployment & Tools-Tests.  This is better
long-term (can pattern e.g. match off Foo-Deployment) but more work
up-front than moving Tools-Tests to ToolsTests.

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131209/7c0d0607/attachment.htm


More information about the Squeak-dev mailing list