[modules] What should be the first step?

Phil Weichert weichert at hal-pc.org
Sat Aug 18 19:47:39 UTC 2001


I agree that what Dan has proposed is a great place to start.  Dan proposal brings a breath of sanity to the discussion of modules.  He has kept it simple (not to imply that this is not a LOT of work to get to the proposed modules) and made it easy to understand.  Dan's proposal seems to fit well with a number of points made by Allen Wirfs-Brock

To help me envision this, where and how do extensions to basic mathematical functions and operations contain in current packages like MathMorphs and Math Pack fit into your scheme?    Would these be a series of dependent modules that stepwise add the basic functionality:  For Example:
Complex number module (no dependents)
Vector (array of numbers) module
Statistical module (dependent on Vector)
Matrices module (dependent on Vector)

Many thanks to Dan!
Phil

Dan Ingalls wrote:

> --
> Folks -
>
> I'm afraid there is much more about all of this that I don't know than that I do know.  That said, perhaps it can be an advantage...
>
> I know there are several things we are talking about here, and we need to separate them to come up with clear solutions.  What I'd like to do is to propose an operational approach which may help to guide us to getting the "best of both worlds" -- in this case a simple small kernel, but that can support a great group programming engine for large software projects.
>
> [If you're in a hurry, skip to *****
> Here's what I mean by an operational approach -- think of how we might release the Squeak system:
>
> 1. A minimal kernel
> This would be something like the 240k "tiny" image I made from Squeak a few years ago (had compiler, files, minimal graphics (only enough to put up a transcript), collections, strings and numbers).  I would like to go farther with this by using the OS for the transcript, so that all this thing can really do is read in the next package.
>
> 2. Basic Graphics
> This would be the kernel graphics (Form, Color, etc) common to MVC and Morphic.
>
> 3. Full Files
> The kernel might only know about the current directory.  This would fill out the rest, along with all the stuff there now that isn't essential.
>
> 4. Development system kernel
> All the browser models
>
> 5a. MVC kernel
> Enough to support MVC applications
>
> 5b. Morphic kernel
> Enough to support simple Morphic applications
>
> 6a. MVC development system
>
> 6b. Morphic development system
>
> You can take it the rest of the way, through network support, network applications, 3D support, 3D applications, scripting system, etc.  The important thing, that I doubt any of us disagree with, is that the image is built up in a modular way, so that you could do a headless server or a small squeak for PDAs with no space wasted for the other modules you are not using.  Ideally, you could end up with the exact same system whether you built it up from the kernel, or pared it down from a jumbo system -- the modules should be loadable or unloadable in a completely, well, modular manner.
> *****]
>
> What does this say about our architecture for modules?  To me it says that what we want to start with in the image is really just the support necessary to receive a new module.  This looks like a fairly small requirement -- it could be satisfied by a combination of Lex's ChangeSet proposal and the existing Environments work, with some cleanups and simplifications.  I'm curious if people generally agree about this and, if so, if it would be worth summarizing this requirement as a sub-project of the overall effort.
>
> A parallel sub-project would be to extend our tools to work with this new architecture.
>
> This would seem to be the first step to shoot for, because it would enable...
>
>         1.  A refactoring of the entire system
>             along the lines above
>
>         2.  More reliable and consistent sharing
>             of major projects in the community
>
>         3.  A target image specification for the
>             more serious team development tools
>             which could themselves be added as modules.
>
> Do people think this is a reasonable first step?
>
> Does anyone want to propose a spec for what needs to be done?
>
>         - Dan





More information about the Squeak-dev mailing list