>> So you want to have a bunch of 3-method micro-packages like Pharo, so
>> that when you open Monticello and see 257 packages and also it's a
>> pain in the ass to define configuration scripts because of this?
>
> I didn't know that a simple recategorisation would get such a hot response!

I didn't mean to sound hot as much as just, "hold on a sec here, let's
talk about this."

> Even if I did rip Compression apart - which it seems now that I don't
> need to do - you would neither know nor care about it in your
> configuration scripts unless you were doing something highly
> specialised like making a near-minimal image.

Mmm, well, even if I wasn't making a highly specialised like making a
near-minimal image, I'd still have to know which one to load _first_
-- either Compression-Archives or Compression-Streams.

> And if you _were_ making such a special image, I suspect you'd _want_
> such precise control.

Either that or the ability to _unload_ what I don't want.

There is _no way_ to make a truly minimal-for-a-vertical-purpose image
by only adding packages to a micro-kernel.  This is why I think the
"hundreds of tiny hyphenated packages approach" taken by Pharo is
wrong.  You will always end up with extranneous methods you don't need
unless you unload them.

*Except* in the case of imprinting via Spoon, of course.   :)

> But when you've read my other mail you'll see it's a fool's errand to
> try split Compression into Compression-Archives and
> Compression-Streams because you'd just have a cyclic dependency
> between the two. I'm trying to remove _all_ cyclic dependencies.

Good, we do need to eliminate the cycles between packages.  I hope it
can be done without needing to introduce new framework and/or package
layers.

Thanks..

>
> frank
>
>> On Wed, Jul 17, 2013 at 3:53 AM,  <commits at source.squeak.org> wrote:
>>> Frank Shearar uploaded a new version of Compression to project The Trunk:
>>> http://source.squeak.org/trunk/Compression-fbs.37.mcz
>>>
>>> ==================== Summary ====================