>>> Yes, but the stripping out part is manual. Well, it's scripted [1],
>>> and when a new package becomes unloadable I add it to the script, run
>>> ... snip ...
>>
>> I was thinking about something.  Your Stripping script, and any
>> external ".st" script for that matter, should be a one-liner simply to
>> call one single method, rather than having any sort of code with
>> implementation details.  One reason for this is so that browsing
>> senders will miss as little as possible due to being externalized in
>> an .st script.
>
> I'm prepared to be argued over to agreeing with you, which means that
> at the moment I don't :). The reason is that I don't see a car factory
> inside my car: the car factory assembles a bunch of bits and gives me
> a car. (This is one of the things that annoys me about Metacello: I
> don't want to see ConfigurationOfs in my image.)

Good luck with that car company.  :)  A factory with no development
tools, and no visibility from the "car", I predict a crash at some
point in the near future (pun intended).   :)

I guess I regard the the image as both car AND factory.  We're dealing
with a car that has the ability to mutate from a Cadillac into a
Prius, why shouldn't that capability be visible and managed under the
same powerful dev tools as everything else?

>> There are two scenarios for deploying a minimal production image.  The
>> "conventional" way, used by other languages, is to develop the code
>> base in a rich fat image and, when its ready, version it all up and
>> Assemble it manually into a brand new SqueakTrunk image, sans all the
>> richness.
>
> No. The usual mainstream approach is the opposite: it builds an
> application up from a bunch of libraries together with your own code
> to produce a binary. That binary doesn't have an IDE in it, or a
> debugger, or anything else that I'd expect from a rich fat image.

That's exactly what I said.  "Assemble".

> Stripping is _hard_. Just look at all the Self literature. (My brief
> Googling has failed me, but I did read an interesting approach in
> connection with abstract interpretation.) Well. It's very easy to
> remove things from an image. The problem is removing only the bad bits
> and leaving the good bits.

"Strip" is not a good word because it evokes all the complicated
graph-traversal stuff like deploying a "stripped" image from
VisualAge.  I'm simply talking about large-grained "unloading
extranneous packages", which have no bearing on an app, just as you do
with your .st script, for the purpose of running in production with a
smaller image.

But, I want to be able to TEST my application with a...  let's call it
"Reduced" image without having to version all code and re-Assemble it
into an entirely new image first.  Smalltalk embraces the idea of live
and continuous evolution of software, and so Reduce will be needed
much more often than Assemble.

>> The other way, supported only by Smalltalk, is where I start with a
>> ReleaseSqueakTrunk image (rich and fat) and develop my code and
>> objects until I'm ready to deploy.  Instead of being required to
>> hand-assemble a new image I simply Strip the image I'm in and deploy
>> that.
>>
>> (As I type this e-mail, the merits of Spoons approach continue to woo
>> me.  Craig?!)
>
> As Eliot put it, Spoon and my packaging work are pushing two different
> things: Spoon produces _minimal_ images, while I'm trying to produce
> _modular_ images. If you think of the two processes as vectors,
> they're _broadly_ in the same direction, but they're not parallel.

Maybe you could help me understand -- what is the benefit of
"modularity" at the package level?

We all grok the benefit of *functional* modularity -- where individual
methods do one and only one thing and individual classes embody a
coherent and limited group of related behaviors.  This allows programs
to be more understandable and upgradeable.

But what is the benefit of *package* modularity?  To me, it relates to
_image size_ and little else.  Less code is easier to understand than
more code, it takes up less memory, and probably runs faster.

But besides that, more packages complicates Assembly.  And Reduced
images are less capable of dealing with bugs due to lack of IDE tools.

So, I guess I don't know what a "modular" image is or why I would want
one.  My use-cases are I want Rich for development, and Reduced for
production.  Both Spoon and your "modularisation-of-packages" work
seem equally aimed at the latter goal.  If not, then for what do I
want Modular?

Thanks.