FWIW -

I, too, am very happy to hear of projects being revisited.  It always seemed to me that a Project was *just* a sub-Squeak.  It's so with regard to Display area, it's so with regard to changes and (when the planets are lined up right) it can even be so with regard to an ImageSegment as part of the image.

As Tansel points out, global variables and similar referential issues were the bane of the image segments.  I (and Ted K) worked hard to deal with this problem back in the day, and I tried redefining Smalltalk as a Project-local Dictionary ("Environment") linked to the dictionary of its parent project.  I don't know if this kind of inheritance structure is best in general, but at one time the reorganizeEverything method actually restructured the whole system this way, introduced a name-space approach to cross-module references, and kept running afterwards.

The motivation (which began with the need to support Alan's mondo 200M images with 100 projects) was to keep the "kernel" image small, and to load and unload projects as swapping units.  But the same unit served well to divest the image of big categories like VM construction, EToys, etc (though this was just two levels, not deep).  The one thing I did differently from most of the other namespace proposals was to make global references be (capitalized) messages to the module dictionaries.  This had the nice property that, if you worked on a new Stream package called MyStreams, then simply executing, eg,
	OriginalStreams := KernelStreams.
	KernelStreams := MyStreams.
Would cause all code to start using the new streams, and it could all be reverted atomically with
	KernelStreams := OriginalStreams
One could do this on a project-local basis too, allowing for multiple coexisting versions.
[There are other reasons for having global references be messages]

Henrik Gedenryd picked up this work and carried it quite a bit farther into the system and sadly things got a bit too incompatible.  It was a big frustration for me (and for him++) that we never managed to pull this off to completion.

I wouldn't want to interfere with Andreas's nice suggestion.  But I do think there's much more possible if anyone gets interested.   Don't know if Spoon uses the synergy of projects as modules.

	- Dan
-----------------------------

>This is great news!
>
>I have always liked projects but my earlier attempts of trying to separate them from images didn't go smooth and I had difficulty moving projects between images.  (Anyone remember trying to save projects from within SqueakNews issues?) In hindsight most of them were due to lousy global variables or some complex relationships but even a smarter extraction process that can inform potential problems will go a long way. Mobilization of projects a la Squeakland but on a grander scale will greatly enhance the ability to make "the experience" of being in an object world much more attractive.
>
>Tansel
>
>
>On 26/11/2009, at 3:25 PM, Andreas Raab wrote:
>
>>Folks -
>>
>>I always felt that one of the least used "big ideas" in Squeak is that of projects. Projects are incredibly powerful but have often been severely misunderstood. A Project in Squeak can define an entire environment (MVC, Morphic, Tweak), it can be a modification to an existing environment, it can identify a set of tools to be used in some context and more.
>>
>>The progress that we've made with refactoring of class Project makes it feasible to illustrate the power of projects. If you install the attached change set in an updated trunk image, you will find a new type of project available - a  GamesProject. When you choose this type of project you will notice that it downloads and installs the MorphicGames package that Edgar just announced (thanks Edgar!), sets up the environment with a set of games before launching into it. (note that I didn't go as far as setting up the menu bar with games, removing the tools, sealing the programmer facilities etc. but all of this is possible and should be considered for the various types of projects)
>>
>>And of course, when we ship the next image, we could actually include a number of such "proto projects" like the GamesProject - it takes a tiny amount of space but makes it very accessible and very visible from an user point of view. As a conseqence, we can hopefully ship the next Squeak version with (proto-)Games, Etoys, VMMaker, Seaside and whatnot projects.
>>
>>Thoughts?
>>
>>Cheers,
>> - Andreas
>>
>><GamesProject.st>