Hi Chris,

On Mon, Feb 1, 2016 at 7:55 AM, Chris Muller <ma.chris.m at gmail.com> 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?
>
> > 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.  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.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160201/20234f80/attachment.htm