On Mon, Feb 1, 2016 at 12:58 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> On Mon, 1 Feb 2016, Chris Muller wrote:
>
>>>>>> I guess the distinction between “Kernel” and “System” isn’t quite
>>>>>> clear
>>>>>> to me.
>>>>>
>>>>>
>>>>>
>>>>> I guess, for me, Kernel contains those things that are essential to a
>>>>> running Smalltalk image. System contains stuff that's generally useful
>>>>> to most things - most, but not all.
>>>>
>>>>
>>>> I've long thought that we'll eventually move Array, OrderedCollection,
>>>> Set and Dictionary to Kernel so that Collections could be unloaded...
>>>>
>>>
>>> You'd also have to move their superclass hierarchy,
>>
>>
>> Of course.  That was implied.
>>
>>> so that wouldn't really
>>> work.
>>
>>
>> Why not?
>
> Because that would mean moving at least 20% of the classes of the
> Collections package.
>
>>> There's no need to have a single "kernel" package containing all
>>> essential
>>> classes, so IMHO it's better to have many kernel packages.
>>
>>
>> "Many kernel packages" is what we have now.  So what are we talking
>
>
> No, we don't. We have some packages with mixed roles. Instead of moving the
> kernel-related collection classes from Colletions to Kernel, you could just
> create a new package, e.g. Kernel-Collections, which would contain these.
> Such smaller packages can greatly simplify the dependencies between
> packages.

In my mind, the overarching goal at the end of the day is to have a
system that is both navigable and comprehensible (as Eliot said),
while at the same time being easy to configure and use.  By making a
bunch of new tiny packages for every node in the category-hierarchy
(i.e., Collections-Abc, Collections-Xyz, Colections-Qrs, etc.), Pharo
accomplished the former, while sacrificing the latter.  The burden was
simply offloaded to configuration.

Fine-grained packages represents the worst of both worlds -- they
don't necessarily solve circular-dependency issues, and yet, they
greatly increase configuration burden onto users.

(.. And still can't configure a truly minimal system, because even
those tiny packages still contain more than is needed (albeit, not AS
much more).  /True/ minimalism can only be achieved by unloading
behaviors (classes and methods), not packages.)