----- Original Message ----- From: Mark van Gulik ghoul6@home.com To: squeak-dev@lists.squeakfoundation.org Sent: Saturday, October 27, 2001 2:27 AM Subject: Re: [ENH][Modules] Delta Modules [was: Another version]
Here's an idea: I think the idea of being able to manipulate and analyze modules *without* loading them is sufficiently important that the initial release of the module system should *not* actual support module loading.
That's how I started out with Oasis. Initially, just a buffer in which I could load code and then do some quick and dirty analysis on it. It is quite a bit more than that now. ( http://sabine.canis.uiuc.edu:8080/Oasis ).
Such a system will still be useful for *describing*, say, how to partition an image.
Yes- there are a number of things that I've built for Oasis before or am working on now to support just this sort of thing.
Come to think of it, the actual loading should be a completely separate, er, module. That way you can use it for directly assembling production images from makefiles (without ever running a single bytecode of that image).
Well, technically there is some truth to that. Smalltalk/X does something like this, and I think that AOS also does this. But there is more to the story than drawing lines in the image- the code that is there has to change as well. The deepest non-modularities in Sqeuak are basically human programming practices which are at odds with a nice clean decomposition. Tools can't change that- but they can make it more apparent, and perhaps provide a bit more firepower for certain operations.
You'll also have a nice *clean* structure (unfettered by the implementations of method dictionaries and symbols etc) with which to perform analysis. Actual loading of modules into an existing image should almost be an afterthought.
LIke Allen says, by the time the stuff has come back into the image, the hard work has been done.
Sure, people will *want* it, but I think these other properties might be more important.
Initially, yes- I'm very hesitant to commit to a particular approach without having had the time to propose, explore, and throw away several of them. I've been at it off and on for 5 years, so I'm very wary of quick-fix solutions, and in particular any proposals that start with the word "just". ( or "simplest thing that could possibly work"... lets define "simplest", "thing", "could" and "work" why don't we? ).
- les