Module discussion

Doug Way dway at riskmetrics.com
Mon Nov 11 02:00:16 UTC 2002


Some other things that came up during the modules discussion (that I 
forgot to mention when we created this summary) were various other 
aspects of module systems such as module unloading, dependencies, 
namespaces, etc.

The general feeling seemed to be that we don't have to have all of these 
features present in a "module system" before we start breaking out stuff 
from the image, and that these features could be added incrementally to 
Squeak.  Some features such as dependency management would be useful 
sooner rather than later, to help manage the broken-off packages.  Some 
people thought package unloading would be very useful (and I tend to 
agree), but no one thought it was needed right away, and Michael made 
the point that it can be a tricky feature to get right.  There didn't 
seem to be much demand for adding namespaces in the near term.

Anyway, these were my additional impressions from the meeting.

- Doug Way
   dway at riskmetrics.com


On Thursday, November 7, 2002, at 03:39 PM, Michael Rueger wrote:

>
> Modules discussion
>
> Before the SqueakBOF a bunch of Squeakers met for about 1 hour to
> discuss the current situation regarding "modules". It is a complex
> question that covers many different areas that are often mixed up. There
> were approximately 15-20 (?) Squeakers present including Michael Rueger
> (representing SqC), Doug Way, Ned Konz, Avi Bryant, me (Göran Hultgren),
> Stephen Pair, Roel Wuyts and many others.
> At SqC there is a lot of interest and Dan said he'll pen a response 
> from SqC later today regarding these and other related topics.
>
> Here are the preliminary "decisions" that came out of that meeting:
>
> 1. We decided to abandon the Modules system currently begun in 3.3alpha
> and freeze 3.3alpha, because it will be very hard to "undo" it. We will
> salvage all the updates in 3.3a that are not related to Modules.
> According to Michael, Scott Wallace has already put quite some effort 
> into this and a first 3.4 release could be out very soon.
>
> 2. We will create 3.4alpha from the current 3.2 and push the salvaged
> updates into that.
>
> 3. We will salvage image refactorings that have been made in 3.3alpha.
>
> 4. We move forward with the "lightweight route" that SM and DVS gives us
> today. This means that SM goes into the 3.2 update stream (and of course
> it will also be in 3.4alpha) and there is a green light to start
> breaking out stuff from the 3.4alpha image into packages on SqueakMap.
> This process should of course be done cooperatively and coordinated.
> Thus, piece by piece the image will shrink and the maintenance
> responsibility for Squeak will become more and more distributed.
>
> 5. The green light for the "lightweight route" means we will also start
> thinking about adding support for package releases and dependencies
> between those in SM, but this really needs to be discussed in more
> detail before being adopted.
> For the time being there will be no packaging mechanism in the standard 
> image. People are free to use DVS or other tools to organize their work 
> and load it into the standard image through e.g. SqueakMap.
>
> 6. The image will remain a centrally managed base using the update
> stream as before, but given SM and tools like DVS it will start to
> shrink and individual maintainers can start managing their own packages
> outside of the image.
>
>
> Göran, Doug, Ned, Michael
>
>
>
>




More information about the Squeak-dev mailing list