[ENH][Modules] Another version

Dan Ingalls Dan at SqueakLand.org
Thu Sep 13 17:23:32 UTC 2001


>Here is an updated version of the modules prototype from a couple of weeks
>ago. (File into 3.1a-4332 in the given order, or strange bugs may happen. I
>have tested it to some extent and it worked for me...)
>
>Much following Les' suggestion, this is as yet a "weak modules" scheme that
>partitions the system into modules but still leaves the critical name lookup
>mechanisms in place (e.g. #Smalltalk). Still, the changes are irreversible,
>mostly because the SystemOrganizer is replaced by an object that simulates
>system categories from module paths. (The path is the location of a module
>within the virtual module hierarchy, and serves to uniquely identify every
>module in every squeaker's project. Hans-Martin's original modularity
>posting is worth re-reading, some ideas are virtually identical to this
>system.)

Henrik, this is great!

I'm amazed how much ground you have covered in so little space.  I hope those interested will try out your code, experiment with it, and think about what needs to be done to accomplish the first level of goals for modularity in Squeak.

[Incidentally, I have learned that the suggested installation,
	Module convertSystemOrganizationToModules.
is not optional.  From this point on, everything seems to work quite well.  If you do not do this, then backward compatibility is a bit shakier, and you need courage to proceed through various errors when defining classes]

This is a great start on a module system for Squeak.  While it may not fill all the needs of commercial developers (support for cross-dialect development, etc), it does not preclude such tools, and...
	it is small
	is is simple
	it is non-invasive ('weak' in Les's sense)
	it includes name spaces
	it addresses incremental updates
	it provides for incremental refactoring from the community.

Here are some experiments that I think would be fun to start on, even in this preliminary state (may require some further work on fileOut/In)...

	Enhancing our tools to work with modules
	(Henrik has done a fair amount of this,
	but there is more to be done).

	A good factoring of our monolithic image
	(again we have a start)

	Make majorShrink (and other shrinks) work cleanly.
	I think of this as unloading weak modules.
	It will be an iterative process of refactoring,
	reducing dependencies, and rewriting majorShrink.
	In the end, majorShrink should simply be a series
	of unload commands.

	A useful demo would be to have a couple of packages
	such as Connectors, ThingLab, or MathMorphs that
	could be loaded and run, and then unloaded.
	The demo would be to show that 'space left' was
	the same after as before.

	Related to this would be the ability to unload
	various modules from our current image, and then
	reload them from their files, and have everything
	work again.  When this works everywhere, we will
	have accomplished the deconstruction of Squeak.

	We can also now start to address modularity of
	projects, which could evolve into a component
	architecture for Squeak.

Thanks again, Henrik, for carrying this through to where it can be seriously evaluated.

	- Dan
-- 




More information about the Squeak-dev mailing list