Having Collection and Kernel dissociated is a very difficult thing, because Array, ByteArray, String, Symbol ... are all used in the Kernel. At least if Kernel contains the very basic stuff used by the VM.
See http://stackoverflow.com/questions/17176380/inconsistencies-in-smalltalk/171... viewing a small part of those inter-connections.
The object map of a minimal Spoon image might also be of interest (can't find the link right now).
2013/7/29 Frank Shearar frank.shearar@gmail.com
On 29 July 2013 14:13, Tobias Pape Das.Linux@gmx.de wrote:
Am 29.07.2013 um 14:51 schrieb Frank Shearar frank.shearar@gmail.com: […]
IMHO we should start with Collection and make it depend on 'Nothing', or the other way round, make Collection depend on Kernel but Kernel
depend
on nothing.
I would very much like to have Kernel depend on nothing, but we're a long way from being able to do that.
Why? (see below)
Well, we can attack the inter-package dependency problem from anywhere. I just wanted to untangle System, and get Etoys/MorphicExtras/Morphic unloadable before potentially frightening people with "extreme" stuff like gutting Kernel of arithmetic, and pulling ByteArray and such into Kernel (because ByteArray subclass: #CompiledMethod).
Collections _can't_ depend on nothing, because it must at the least depend on things like Object and Class, which properly belong in Kernel.
I looked around in Kernel and, boy, it is crowded. Eg, why is ObjectViewer in Kernel? (just mocking)
Decades of noone getting really serious about package dependency management in a giant blob of persistent state will do that every time :) That's mostly easy to fix though.
Wouldn't it be possible to extract the actual kernel from "Kernel" and rename Kernel to Base or something? Only that we have the most basic objects (Object ±ProtoObject, Booleans,
MNU (with dependencies))
Agreed.
frank
Best -Tobias