<div dir="ltr">Hi Chris,<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 7:55 AM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">>>>> I guess the distinction between “Kernel” and “System” isn’t quite clear<br>
>>>> to me.<br>
>>><br>
>>><br>
>>> I guess, for me, Kernel contains those things that are essential to a<br>
>>> running Smalltalk image. System contains stuff that's generally useful<br>
>>> to most things - most, but not all.<br>
>><br>
>> I've long thought that we'll eventually move Array, OrderedCollection,<br>
>> Set and Dictionary to Kernel so that Collections could be unloaded...<br>
>><br>
><br>
> You'd also have to move their superclass hierarchy,<br>
<br>
</span>Of course. That was implied.<br>
<span class=""><br>
> so that wouldn't really<br>
> work.<br>
<br>
</span>Why not?<br>
<span class=""><br>
> There's no need to have a single "kernel" package containing all essential<br>
> classes, so IMHO it's better to have many kernel packages.<br>
<br>
</span>"Many kernel packages" is what we have now. So what are we talking<br>
about then? Just moving things around to different packages based on<br>
some "improved" notion of subjective semantic classification, with no<br>
regard for the physical system dependencies? Why would that be<br>
beneficial?<br>
<br>
Are Symbols part of any Smalltalk's Kernel? Yes, so what benefit is<br>
it to have it in Collections?<br>
<br>
Is LRUCache part of any Smalltalk's Kernel? No, but if its in<br>
Collections along with Symbol, then I'm forced to remove it manually<br>
after loading "many kernel packages" if I just want a Kernel system...<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div><div><br></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>