>> > You'd also have to move their superclass hierarchy,
>>
>> Of course.  That was implied.
>>
>> > so that wouldn't really
>> > work.
>>
>> Why not?
>>
>> > 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
>> about then?  Just moving things around to different packages based on
>> some "improved" notion of subjective semantic classification, with no
>> regard for the physical system dependencies?  Why would that be
>> beneficial?
>>
>> Are Symbols part of any Smalltalk's Kernel?  Yes, so what benefit is
>> it to have it in Collections?
>>
>> Is LRUCache part of any Smalltalk's Kernel?  No, but if its in
>> Collections along with Symbol, then I'm forced to remove it manually
>> after loading "many kernel packages" if I just want a Kernel system...
>
>
> So let's imagine we're wise and we look forward and we structure the classes
> in Collections to play well with the category names in Collections, so that
> all the superclasses of classes in Collections-Abstract,
> Collections-Arrayed, Collections-Exceptions, Collections-Sequenceable,
> Collections-Strings and Collections-Support that are themselves Collections
> classes are in just those categories.  Now I can unload all Collections-blah
> categories except Collections-Abstract, Collections-Arrayed,
> Collections-Exceptions, Collections-Sequenceable, Collections-Strings and
> Collections-Support.  Because when I look at Collections I see that those
> six categories are those that provide the minimal subset of Collections that
> supports the core language's set of literal collections.

*You* can see that, a newbie couldn't.  A newbie would have no way to
know what all packages would be needed to simply have a "kernel"
system.  They would wonder why they couldn't just load "Kernel", huh?
If the hierarchy for those would be reversed, as in,
Kernel-Collections-Abstract, Kernel-Collections-Arrayed,
Kernel-Collections-Exceptions, Kernel-Collections-Sequenceable,
Kernel-Collections-Strings and Kernel-Collections-Support, THEN we've
actually got a match between the newbie's semantic notion of a
"Kernel" with the actual physical reality of what the system needs.

The top-level(s) of the category defines the Package.  I don't believe
this needs to be a compromise.  Let the top-level(s) determine the
package, based on *physical* dependency within the system, while the
2nd thru lower levels define the semantic (sub)categorical
organization within the system.

>  It provides more,
> but it is the minimum to provide Array, ByteArray, ByteString, WideString,
> Symbol, ByteSymbol and WideSymbol.
>
> Now, if that analysis is correct would it be better to change the package
> structure to have Collections-Kernel and Collections-PotPourri, with
> categories like Collections-Kernel-Abstract, Collections-Kernel-Arrayed and
> so on, or have some other convention such as a class-side method on
> Collection that defines the kernel categories?  I don't know.  I do know
> that there's real pedagogical value in having the six (and other) categories
> above, and I don't think we should reduce the navigability and
> comprehensibility of the system to make package structure serve the needs of
> decomposition rather than the needs of the newbie.  The bug is that packages
> use categories.  It's a functional compromise, but it's a little
> uncomfortable.  But the key point is that your point above about LRUCache is
> a bit of a straw man.  If we manage the categories in Collections wisely we
> can do what you want without too much difficulty.